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ABSTRACT 


Language  directed  computer  design  is  an  approach  to  designing 
computers  which  implements,  in  the  machine  hardware,  operations  and  data 
structures  normally  associated  with  high-level  programming  languages. 
This  dissertation  examines  the  use  of  scientific  experimentation  as  a 
tool  for  the  design  and  evaluation  of  language  directed  computers. 

In  Chapter  1  the  language  directed  design  process  is  described  and 
a  historical  survey  of  language  directed  computers  is  presented. 

Chapter  2  discusses  measurement  of  computer  performance  in  terms 
of  a  cost-benefit  function  and  then  describes  how  experiments  may  be 
constructed  to  improve  the  design  of  existing  computers  and  to 
evaluate  computer  performance. 

In  Chapters  3-6  the  experimental  techniques  are  illustrated  with 
a  case  study  of  the  design,  improvement  and  evaluation  of  a  language 
directed  computer  which  implements  a  dialect  of  PL/I.  Chapter  3 
defines  a  PL/I  dialect  called  Student  PL.  Chapter  4  begins  with 
the  definition  of  MDL,  an  Algol-like  notation  for  describing  computers. 
An  initial,  zero-address  stack  computer  designed  to  implement  Student 
PL  is  then  presented  in  terms  of  MDL.  In  Chapter  5,  experiments 
are  conducted  to  improve  the  design  of  the  initial  machine.  The 
design  improvements  suggested  by  the  experiments  result  in  substantial 
improvements  in  machine  performance. 

In  Chapter  6  the  experimental  techniques  for  evaluating  computer 
performance  are  used  to  compare  the  improved  Student  PL  machine 
with  a  contemporary  general  purpose  computer,  the  IBM  System/ 360. 

In  terms  of  traditional  measures  of  computer  performance  (number  of 
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instructions  executed,  number  of  bits  of  information  accessed,  number 
of  memory  references  required)  the  Student  PL  machine  is  shown  to 
be  considerably  more  efficient  for  the  execution  of  Student  PL 
programs . 

Chapter  7  concludes  the  thesis  with  a  summary  of  results  and 
some  suggestions  for  future  research. 
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Preface 


This  thesis  had  its  origin,  as  many  theses  do,  in  a  frustration 
with  the  status  quo  and  a  naive  feeling  that  it  should  be  easy  to 
do  things  better.  In  our  case,  we  were  upset  by  the  immense  effort 
involved  in  implementing  compilers  for  sophisticated  programming 
languages  on  contemporary  general  purpose  computers,  and  by  the 
gross  inefficiency  of  the  resulting  object  programs.  Contemporary 
compilers  on  many  computers  are  large  slow  programs  which  emit 
large  slow  programs. 

At  first,  language-directed  machine  design  appeared  to  be  the 
panacea  which  would  cure  the  problems  we  were  experiencing.  Somewhat 
later  it  became  apparent  that  language-directed  design  doesn’t  yet 
have  all  the  answers.  If  a  programming  language  is  very  well 
structured  (e.g.,  close  to  mathematics)  then  it  is  possible  to  design 
a  computer  to  implement  it  and  to  demonstrate  in  a  convincing  way  that 
the  design  is  "good".  However  for  programming  languages  with  a  less 
elegant  structure  (e . g .,  FORTRAN ,  COBOL,  and  PL/I)  the  design  problem 
is  much  more  difficult.  One  of  the  main  problems  seemed  to  the 

machine  designer's  lack  of  information  about  what  programs 
actually  do  during  execution.  We  therefore  took  as  our  goal 

the  development  of  new  design  tools  to  aid  the  designer  in  building 
computers  which  satisfied  the  actual  rather  than  the  imagined  needs 
of  the  programmer.  As  our  work  progressed  it  became  clear  that  the 
tools  we  were  developing  could  also  be  used  by  the  programmer  to 
evaluate  the  performance  of  computers  in  terms  which  were  relevant 
to  the  task  of  producing  efficient  software. 
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The  original  suggestion  to  consider  language  directed  design 
came  from  Professor  W.M.  McKeeman.  He  and  Professors  Harold  Stone 
and  James  J.  Homing  have  been  most  generous  in  providing  help, 
advice  and  encouragement  when  it  was  needed.  Professor  D.R.  Reddy 
deserves  credit  for  teaching  the  introductory  programming  bourse 
which  used  Student  PL.  The  research  reported  here  was  initially 
made  feasible  by  the  support  of  the  Stanford  Computation  Center, 
Campus  Facility  and  its  director  Mr.  Rod  Fredrickson.  Support 
to  complete  this  work  was  provided  by  the  National  Research 
Council  of  Canada  through  the  Computer  Systems  Research  Group 
at  the  University  of  Toronto. 

This  thesis  is  dedicated  to  Ginny,  who  is  still  my  wife 
in  spite  of  it  all. 


Table  of  Contents 


1  The  Problem  1 

1.1  Introduction  1 

1.2  The  Problem  3 

1.3  Historical  Perspectives  5 

2  Design  and  Evaluation  8 

2.1  Introduction  8 

2.2  Experimentation  in  Machine  Design  10 

2.3  Experimentation  in  Machine  Evaluation  12 

2.4  A  Case  Study  16 

3  Student  PL  18 

3.1  Introduction  18 

3.2  Data  Types,  Variables  and  Scalar  Expressions  19 

3.3  Array  Arithmetic  20 

3.4  Programs,  Blocks,  Procedures  21 

3.5  Declarations  and  Storage  Management  22 

3.6  Assignment  Statements  22 

3.7  Input  and  Output  23 

3.8  Builtin  Functions  23 

3.9  Conditional  Statements  26 

3.10  GO  TO  Statement  26 

3.11  Groups  27 

3.12  Example  27 

4  The  Student  PL  Machine  29 

4.1  Introduction  29 

4.2  Storage  35 

4.3  Data  Access  and  Addressing  49 

4.4  Instructions  for  Infix  and  Prefix  Operators  54 

4.5  Sequencing  and  Control  61 

4.6  Block  and  Procedure  Instructions  65 

4.7  Array  Storage  and  Utility  Instructions  70 

5  Design  Improvement  74 

5.1  Introduction  74 

5.2  The  Economics  of  Change  76 

5.3  Characteristics  of  Student  Programs  78 

5.4  Instruction  Distributions  86 

5.5  Addressing  and  Data  Access  92 

5.6  Constants  99 

5.7  Conditional  Statements  102 

5.8  Builtin  Functions  106 

5.9  Other  Changes  108 

5.10  Closing  the  Loop  110 


- 


6  Experimental  Computer  Evaluation  127 

6.1  Introduction  127 

6.2  Experiment  Parameters  128 

6.3  The  Evaluation  Experiment  131 

6.4  Evaluation  Considerations  157 

7  Conclusions  161 

7.1  Summary  161 

7.2  Future  Research  164 

Bibliography  265 

Appendices 

A.  A  BNF  Description  of  Student  PL  169 

B.  Implementation  of  Student  PL  Statements  176 

C.  Student  Programming  Assignments  186 

D.  Additional  Machine  Statistics  188 


List  of  Tables 


3.8.1  Builtin  Functions  24 

4.1.1  Single  Character  Symbols  in  MDL  32 

4.2.1  Simple  and  Composit  Types  37, 

4.2.4  Student  PL  Machine  Descriptors  ^2 

4.3.1  Data  Access  Instructions  31 

4.3.2  Auxiliary  Procedures  32 

4.4.1  The  Operator  Function  0  36, 

4.4.2  The  Operator  Function  <}>  37 

4.4.3  Infix  and  Prefix  Operator  Instructions  39 

4.4.4  Auxiliary  Procedures  60 

4.5.1  Sequencing  and  Control  Instructions  62 

4.5.2  Auxiliary  Procedures  64 

4.6.1  Block/Procedure  Instructions  67 

4.6.2  Auxiliary  Procedures  68 

4.7.1  Storage  Management  Instructions 

4.7.2  Utility  Instructions  72 

4.7.3  Auxiliary  Procedures  73 

5.3.1  Distribution  of  Grammar  Rules  Used  in  Parsing  30 

5.4.1  Instruction  Distributions  37 

5.4.2  Distribution  of  Compiled  Instruction  Pairs  ^1 

5.5.1  Distribution  of  Compiled  and  Executed  Address 

References  as  a  Function  of  Lexical  Level  04 

5.5.2  New  Data  Reference  Instructions  97 

5.6.1  Distribution  of  Constants  by  Type  100 

5.6.2  Distribution  of  FIXED  Constant  Values  100 

5.6.3  The  LITERAL  Instruction  100 

5.7.1  Distribution  of  Length  Field  in  Program  Segment 

Descriptors  Fetched  to  the  Data  Stack  104 

5.7.2  Conditional  Statement  Instructions  105 

5.8.1  Distribution  of  Number  of  Parameters  per 

Procedure  Call  107 

5.8.2  The  BFUNC  Instruction  107 

5.9.1  New  Instructions  109 

5.10.1  Distribution  of  Compiled  and  Executed  Instructions  112 

6.3.1  Programming  Language  Fragments  133 

6.3.2  Tabulation  for  Fragment  208  143. 

6.3.3  Experiment  Assumptions  144 

6.3.4  Fragment  Attribute  Matrix  for  Student  PL  Machine  146 

6.3.5  Fragment  Attribute  Matrix  for  System/360  149 

6.3.6  Performance  Measure  Terms  155 

6.3.7  Test  of  Covering  Error  155 


List  of  Figures 


3.12.1  A  Student  PL  Program  28 

4.2.1  Student  PL  Machine  Storage  Areas  36 

4.2.2  The  Data  Stack  39 

4.2.3  Array  Descriptors  41 

4.2.5  The  Scope  Stack  43 

4.2.6  The  Scope  Table  44 

4.2.7  The  Symbol  Table  45 

4.2.8  Progam  Segment  Stack  46 

4.2.9  Instruction  Fetch  and  Execution  48 

4.4.1  Extension  of  Infix  Operators  to  Array  Operands  55 

5.5.1  Distribution  of  Order  Numbers  as  a  Function 

of  Lexical  Level  93 

5.5.2  Partitionings  of  the  Instruction  Syllable  96 

5.10.1  New  Machine  -  Distribution  of  Order  Numbers 

as  a  Function  of  Lexical  Level  114 

5.10.2  Ratio  of  Program  Size  115 

5.10.3  Ratio  of  Data  Area  Size  117 

5.10.4  Ratio  of  Total  Program  Size  138 

5.10.5  Ratio  of  Total  Program  Size  119 

5.10.6  Ratio  of  Instructions  Executed  121 

5.10.7  Ratio  of  Program  Memory  References  122 

5.10.8  Ratio  of  Data  Memory  References  123 

5.10.9  Ratio  of  Bits  of  Program  Fetched  .124 

5.10.10  Ratio  of  Data  Bits  Fetched  126 

6.3.1  Example  of  Object  Program  Images  142 


Chapter  1  -  The  Problem 


1.1  Introduction 

The  availability  of  high-level  programming  languages  has  become  a 
fact  of  life  for  the  modem  computer  scientist.  In  recent  years 
increasingly  powerful  programming  languages  such  as:  FORTRAN,  COBOL, 
and  PL/I  have  been  devised  to  provide  convenient  notations  for  expressing 
algorithms.  Improvements  in  the  architecture  of  digital  computers  have 
not,  in  general,  kept  pace  with  rapid  improvements  made  in  the  design  of 
programming  languages.  A  relatively  slow  evolution  in  the  design  of 
computers  has  led  to  a  mismatch  between  basic  operations  in  programming 
languages  and  operations  available  in  the  machine  language  of  most 
computers.  The  existence  of  this  mismatch  is  evident  in  the  size  and 
complexity  of  contemporary  compilers  and  in  the  number  of  object  program 
instructions  required  to  implement  source  program  statements. 

One  approach  to  removing  this  mismatch  is  to  structure  computers  so 
that  they  more  directly  implement  the  operations  of  programming  languages. 
Language  directed  machine  design  [Anderson  1961;  Barton  1961;  McKeeman 
1967]  tries  to  fit  computers  to  programming  languages  in  several  ways: 

data  structures  used  by  programmers  map  easily  onto  data  structures 

in  the  machine,  control  constructs  in  the  machine  match  control  constructs 
in  the  language  (e.g.  a  "procedure  call"  instruction),  errors  in  using 

the  language  (e.g.  subscript  out  of  range)  are  detected  by  the  hardware. 

In  brief,  language  directed  machines  reflect  in  their  instruction  sets 

and/or  data  structures,  capabilities  which  are  presently  associated  with 

high-level  programming  languages. 

With  few  notable  exceptions,  designs  for  language  directed  machines 
have  been  based  on  the  intuition  and  experience  of  the  individual  designers 
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and  not  on  an  analysis  of  the  programming  languages.  Abram's  [1970] 
design  of  a  machine  for  APL  is  an  indication  of  what  can  be  done  using 
formal  analysis  if  the  programming  language  is  very  well  structured. 

For  languages  lacking  the  regular  structure  of  APL  an  analysis  similar 
to  Abram's  is  much  more  difficult.  Use  of  ad  hoc  design  procedures  in 
place  of  careful  analysis  is  undesirable  for  many  reasons,  including  the 
lack  of  guarantees  that  the  machine  will  execute  programs  in  the 
language  correctly  or  efficiently. 

A  problem  collateral  to  that  of  designing  language  directed 
machines  is  how  to  evaluate  the  performance  of  these  machines  relative 
to  more  conventional  computers.  In  a  restricted,  well-structured  case 
Abrams  was  able  to  mathematically  analyze  the  relative  performance  of 
his  APL  machine;  however,  a  similar  evaluation  has  not  been  done  for 
most  other  language  directed  machines. 


2 


1.2  The  Problem 


In  this  dissertation  we  consider  alternative  techniques  for  the 
design  and  evaluation  of  language  directed  computers.  Our  primary 
purpose  is  to  provide  new  design  tools  that  can  be  used  in  cases  where 
a  design  and  evaluation  based  on  formal  analysis  is  impractical.  Our 
approach,  experimental  language  directed  machine  design,  was  born  of 
the  realization  that  the  techniques  of  experimental  science  can  be 
applied  to  problems  in  language  directed  machine  design. 

We  explore  separately  the  problems  of  design  and  evaluation.  The 
design  techniques  we  propose  follows  the  pattern  of  classical  scientific 
experimentation.  One  formulates  hypotheses  about  how  well  a  given 
computer  implements  a  particular  language  and  then  conducts  experiments 
to  prove  or  refute  the  hypotheses.  The  results  of  the  experiments  are 
used  to  suggest  improvements  in  the  design  of  the  machine. 

Designs  for  language  directed  machines  have  usually  been  presented 
without  any  evaluation  of  the  merits  of  the  design,  except  for  the 
simulated  or  actual  performance  of  the  machine.  Some  designs,  for 
example  the  Burroughs  B5000  and  the  English  Electric  KDF-9 >  have  been 
good  enough  to  be  commercially  viable;  however,  no  one  knows  how  good 
they  really  are. 

Some  work  on  evaluating  implementations  of  Algol  60  suggested  that 
the  performance  of  a  computer  in  executing  carefully  choosen  fragments  of 
programs  could  be  used  to  measure  overall  machine  performance.  We  have 
expanded  this  idea  into  a  language -directed  technique  for  evaluating 
computer  performance. 

In  Chapter  2  we  describe  more  fully  our  design  and  evaluation 
techniques.  To  illustrate  how  our  techniques  work  in  practice  we  present 
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in  the  following  chapters  a  case  study  of  the  design  and  evaluation  of 
a  computer  architecture  for  a  dialect  of  PL/I.  Chapter  3  describes  the 
dialect  called  Student  PL.  In  Chapter  4  we  define  an  initial  language 
directed  machine  to  implement  Student  PL.  Chapter  5  contains  a  descrip¬ 
tion  of  the  experiments  conducted  to  test  the  design  of  the  initial 
machine.  We  show  that  the  design  improvements  suggested  by  the  experi¬ 
ments  lead  to  substantial  improvements  in  machine  performance. 

Chapter  6  concludes  the  case  study  with  the  application  of  our 
evaluation  techniques  to  a  comparison  of  the  Student  PL  machine  with  a 
contemporary  general  purpose  computer. 

The  main  goal  of  this  thesis  is  to  develop  new  tools  for  the  design 
and  evaluation  of  language  directed  computers.  While  the  question  of 
how  best  to  implement  a  given  language  directed  design  using  available 
technology  is  an  interesting  one,  its  answer  is  peripheral  to  our  main 
purpose.  Given  the  rapid  changes  occurring  in  the  field  of  digital 
electronics'*'  an  answer  to  that  question  is  at  best  of  fleeting  historical 
interest.  Any  specific  hardware  design  we  set  down  on  paper  would 
probably  be  obsolete  before  it  could  be  read.  We  therefore  restrict 
our  attention  to  the  high-level  structural  design  of  digital  computers. 


1.  When  the  research  reported  here  was  initiated,  flip-flops  were  being 
made  from  discrete  components  and  came  packaged  two  per  circuit  card. 
As  the  nth  draft  of  this  document  was  being  written,  a  complete  4-bit 
arithmetic/ logic  unit  could  be  obtained  in  one  integrated  circuit 
package . 
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1.3  Historical  Perspective 


In  this  section  we  briefly  survey  language  directed  machine  designs 
which  had  an  influence  on  our  work.  Designs  for  language  directed 
machines  can  be  divided  into  two  categories  depending  on  the  internal 
representation  used  for  object  programs  and  the  amount  of  transformation 
done  on  source  programs  prior  to  execution.  Source  language  machines 
execute  programs  directly  in  the  source  program  language.  Usually  only 
trivial  transformations  on  the  source  program  such  as  renaming  tokens 
in  the  language  to  conserve  storage  are  performed  before  execution. 
Intermedi ate  language  machines  execute  programs  which  have  been  transla¬ 
ted  into  a  distinct  internal  form  (often  Polish  code) .  Usually 
extensive  transformations  are  made  on  the  structure  of  the  source  pro¬ 
gram  to  make  execution  more  efficient. 

Probably  the  earliest  language  directed  machine  was  the  Burroughs 
Truth  Function  Evaluator  described  by  Burks,  Warren,  and  Wright  [1954]. 
This  relay  machine  evaluated  logical  expressions  entered  in  Polish 
notation.  This  machine  design  is  one  of  the  few  based  on  a  mathematical 
analysis  of  the  input  language. 

Although  FORTRAN  was  specifically  designed  to  be  implemented  on  the 
IBM  700  series  computers'*',  there  have  also  been  efforts  to  design  FORTRAN 
source  language  machines.  Both  Melbourne  and  Pugmire  [1965]  and  Bashkow 
et .  al .  [1967]  describe  machines  for  early  versions  of  FORTRAN.  The 


1.  Early  FORTRANs  were  clear  examples  of  machine  directed  language 
design. 
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machine  instructions  of  both  machines  were  primarily  direct  encodings  of 
FORTRAN  keywords . 

The  Algol  family  of  languages  have  been  popular  targets  for  language 
directed  machine  design.  An  early  paper  by  Anderson  [1961]  describes  a 
source  language  machine  for  a  large  subset  of  Algol  60.  Later  designs 
of  intermediate  language  machines  include  van  der  Poel's  [1962]  machine 
simulated  on  the  Zebra  computer,  the  Algol  pseudo  machine  used  by 
Randell  and  Russell  [1964]  in  their  interpretive  Algol  60  implementa¬ 
tion  on  the  KDF-9,  the  Burroughs  B5000  [Barton  1961;  Lonergan  and  King 
1961],  and  the  computer  for  an  algorithmic  language  described  by 
Myamlin  and  Smirnov  [1968].  Lindsey  [1972]  has  recently  described  a 
machine  being  designed  to  implement  Algol  68. 

Work  on  Algol  and  FORTRAN  machines  led  to  later  efforts  to  design 
machines  for  PL/I.  Goodfellow  [1968]  describes  an  intermediate  language 
machine  which  was  later  extended  by  Pullam  [1969].  Important  charac¬ 
teristics  of  this  machine  include  the  use  of  1,  2,  and  many  address 
instructions,  the  use  of  self  describing  (typed)  data,  and  the  use  of 
stacks  for  storage.  Sugimoto  [1969]  reports  on  a  list  structured 
machine  organization  for  PL/I  based  on  an  intermediate  language  used  in 
PL/I  compilers.  His  machine  also  uses  typed  data  and  multiple  address 
instructions . 

We  have  previously  mentioned  Abram's  design  of  an  APL  machine 
based  on  a  detailed  mathematical  analysis  of  the  properties  of  APL. 

One  of  his  principal  results  was  a  method  for  deferring  many  vector 
and  array  operations  by  replacing  them  with  equivalent  transformations 
on  descriptors  used  to  access  the  vectors  and  arrays.  Thurber  and 
Myma  [1969]  describe  a  much  less  ambitious  source  language  machine 
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for  APL. 


Other  language  directed  machines  which  have  influenced  the  work 
reported  here  include  Weber's  [1967]  implementation  of  a  source 
language  machine  for  Euler,  the  Rice  University  machine  [Iliffe  and 
Jodeit  1962],  Iliffe's  [1968]  Basic  Language  Machine,  and  Kay's  [1968] 
machine  for  the  FLEX  language.  Each  of  these  machines  embodies 
characteristics  typical  of  language  directed  design:  self  describing 
data,  extensive  use  of  indirect  and  relative  addressing,  and  use  of 
stacks  for  data  storage. 

The  technique  we  use  for  evaluating  computer  performance  was 
suggested  by  the  work  of  B.A.  Wichman  [1969;  1970;  1971;  1972]  on 
comparing  implementations  of  Algol  60.  His  method  is  to  select  a  small 
set  of  statements  to  represent  all  statements  appearing  in  Algol  60 
programs  and  then  to  experimentally  measure  the  time  required  to 
execute  each  statement  in  several  implementations  of  Algol  60.  For  a 
given  implementation  the  sum  of  the  statement  execution  times  is  a 
measure  of  the  relative  performance  of  the  implementation.  Unlike  an 
earlier  technique  for  measuring  computer  performance  by  the  time 
required  to  execute  a  particular  mix  of  machine  instructions  [Gibson 
1970],  Wichman's  technique  is  independent  of  the  computer  hardware. 

It  can  be  used  to  obtain  meaningful  comparisons  between  Algol  60 
implementations  regardless  of  the  underlying  machine.  Our  extension 
to  Wichman's  work  involves  associating  other  characteristics  of  computer 
performance  with  statements  or  statement  fragments.  Wichman's  most 
recent  paper  [1972]  also  describes  work  in  this  direction. 
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Chapter  2  Design  and  Evaluation 


2.1  Introduction 

Ideally,  a  language  directed  machine  design  should  result 
from  analysis  of  the  programming  language  to  determine  the  appropriate 
architecture  for  the  machine.  Unfortunately,  most  real  programming 
languages  are  not  amenable  to  formal  analysis  in  this  sense.  Experimen- 
tation  is  an  obvious  alternative  in  cases  where  exact  analysis  is 
impractical.  In  this  chapter  we  describe  how  experimental  techniques 
can  be  used  for  improving  and  evaluating  the  design  of  language 
directed  machines. 

For  both  design  improvement  and  design  evaluation  we  require 
a  measure  which  will  allow  us  to  decide  if  a  proposed  design  improvement 
is  worthwhile  or  if  one  computer  is  better  than  another.  Normally 
one  uses  a  computer  in  order  to  obtain  some  benefits.  In  describing 
our  design  and  evaluation  techniques  we  will  assume  that  a  cost 
measure  is  supplied  as  a  parameter  to  the  machine  designer.  We  will 
further  assume  that  the  measure  is  "reasonable",  i.e.  it  is  an 
easily  computable,  smooth  function  of  some  characteristics  of  the 
machine  which  reflects  costs  incurred  in  using  the  machine.  In 
particular  if 

B.  =  the  benefit  of  alternative  i 
1 

Ch  =  cost  of  providing  alternative  i 

CM.  =  cost  measure  of  alternative  i 
i 

then  we  require  that 

CM.  <  CM.  if  and  only  if  B.  -  C.  >  B.  -  C.. 

1  3  7  l  l  j  j 

For  convenience  we  will  discuss  the  measure  as  if  it  were  a  linear 
combination  of  terms*  (i.e.  a  weighted  average),  but  our  techniques  do 

1.  Frequently  the  terms  will  not  be  completely  independent.  For  example 
see  the  discussion  in  section  5.6. 
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not  depend  on  the  linearity  of  the  measure.  Later  in  this  chapter 
we  will  give  an  example  of  a  cost  measure  which  we  use  in  a  case 
study  of  language  design. 

Computers  are  usually  designed  to  perform  some  set  of  tasks. 
Although  this  anticipated  workload  is  often  stated  in  very  broad 
and  general  terms  (e.g.  "execute  programs  written  in  language  X"), 
it  is  still  an  important  component  of  the  computer  design  process 
since  it  determines  the  performance  characteristics  required  of 
the  machine.  Our  experimental  techniques  assume  that  the  anticipated 
workload  can  be  estimated  well  enough  that  a  set  of  programs 
can  be  selected  to  provide  a  representative  sample  of  the  workload. 

We  emphasize  that  obtaining  a  truely  representative  set  of  sample 
programs  is  an  important  factor  in  achieving  a  successful  computer 
design.  It  may  well  be  necessary  to  expend  considerable  effort 
interviewing  and  observing  prospective  users  of  the  machine  to 
insure  a  representative  sample. 
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2.2  Experimentation  in  Machine  Design 

In  this  section  we  describe  an  experimental  technique  for  improving 
the  design  of  language  directed  machines.  We  assume  that  an  initial 
design  of  the  machine  (arrived  at  by  conventional  means) ,  a 

cost  measure,  and  a  description  of  the  anticipated  workload  of 
the  machine  have  been  specified. 

The  experimental  hypothesis  we  wish  to  examine  is  that  the  given 
design  results  in  a  minimum  value  for  the  cost  measure  when  a 
set  of  programs  representing  the  anticipated  workload  is  executed. 

Since  cost  measures  typically  involve  both  the  static  and  dynamic 
characteristics  of  a  machine,  we  require  a  way  to  execute  programs.  If 
a  prototype  of  the  machine  is  not  available,  it  will  be  necessary  to 
build  a  machine  simulator.  For  convenience  in  our  discussion  we  will 
assume  that  a  prototype  of  the  machine  is  available. 

The  machine  should  be  instrumented  so  that  the  value  of  the 
cost  measure  can  be  computed.  To  do  this  it  is  necessary  to  examine 
the  terms  of  the  measure  and  associate  them  with  components  of  the 
machine.  By  measuring  the  use  of  these  machine  components  the  value 
of  the  cost  measure  can  be  calculated. 

The  next  step  is  to  execute  a  set  of  representative  programs  and 
obtain  the  values  needed  to  compute  the  cost  measure.  Examina¬ 
tion  of  the  experimental  data  may  suggest  two  types  of  design  improve¬ 
ments: 

1)  a  machine  component  which  is  used  very  infrequently  is  a 
candidate  for  being  removed  from  the  machine  if  the  function 
performed  by  the  component  can  be  easily  achieved  in  some 
other  way, 

2)  a  machine  component  which  makes  a  large  contribution  to  the 
value  of  the  cost  measure  should  be  investigated  to 
determine  if  there  is  a  way  to  reduce  its  contribution. 
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After  deciding  on  design  changes  one  then  adopts  t-he  new 
experimental  hypothesis  that  the  changes  improve  the  design  of  the 
machine  (i.e.,  will  result  in  a  smaller  value  of  the  cost  measure.) 
The  changes  are  implemented  and  the  set  of  programs  rerun  to 
obtain  new  data  on  component  usage.  If  the  value  of  the  cost 
measure  increased,  the  proposed  improvements  were  unsuccessful 
(perhaps  because  of  interaction  between  changes)  and  other  design 
changes  should  be  considered.  If  the  cost  measure  decreased  in 
value,  then  the  changes  improved  the  design  changes  can  be  used 
to  suggest  further  changes. 

The  iterative  process:  (experiement ,  improve) +  should 
terminate  when  the  incremental  decrease  in  the  value  of  the  cost 
measure  becomes  small  enough  so  that  the  expected  benefit  from 
making  a  change  is  outweighed  by  the  costs  incurred  in  implementing 
the  change. 


+  means  repeat  one  or  more  times 


2.3  Experimentation  in  Machine  Evaluation 

To  evaluate  the  performance  of  a  language  directed  machine  we  wish 
to  compare  its  performance  (defined  by  a  cost  measure)  with  the  performance 
of  other  computers.  One  difficulty  in  evaluating  language  directed 
machines  has  been  the  lack  of  a  suitable  evaluation  technique.  The 
work  of  Wichman  [1969;  1970;  1971]  on  comparing  Algol  60  implementations 
suggests  that  terms  in  a  cost  measure  can  be  associated  with 
statements  in  a  programming  language  and  that  this  is  a  useful  way  to 
characterize  machine  performance.  Wichman' s  initial  concern  was  with 
execution  speed  although  a  later  paper  [Wichman  1972]  considered  other 
characteristics  of  machine  performance  attributes  in  limited  cases. 

We  have  extended  Wichman 's  technique  in  several  directions  to  pro¬ 
vide  a  more  complete  technique  for  language  directed  machine  evaluation. 
Wichman's  choice  of  the  programming  language  statement  as  a  basic  unit 
of  measurement  is  unsuitable  for  our  purposes.  To  obtain  more  detailed 
information  about  cost,  we  divide  the  programming  language  into 
language  fragments  which  often  constitute  only  parts  of  statements. 

The  partitioning  of  the  language  into  fragments  depends  on  the  language 
itself,  on  the  cost  measure  being  used,  and  on  the  computers 
being  compared.  The  basic  idea  is  to  choose  enough  small  fragments  so 
that  every  term  in  the  cost  measure  can  be  uniquely  associated  with 
some  set  of  language  fragments.  Choosing  too  many  fragments  increases 
to  effort  required  to  evaluate,  choosing  too  few  fragments  will 
decrease  the  accuracy  of  the  evaluation.  There  are  two  necessary 
conditions  on  the  choice  of  language  fragments: 
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1)  the  fragments  must  map  into  non- overlapping  sequences  of  object 
program  instructions, 

2)  the  fragments  must  be  small  enough  so  that  they  do  not  contain 
data  dependent  loops. 

The  first  condition  prevents  a  sequence  of  object  program  instructions 
from  being  counted  twice.  The  second  insures  that  we  will  be  able  to 
handle  the  loop  structure  of  programs. 

The  key  to  our  evaluation  technique  is  the  association  of  terms 
in  the  cost  measure  with  each  language  fragment.  For  example, 
if  the  cost  measure  is  a  weighted  sum  of  the  number  of  instructions 
executed  and  number  of  memory  references  required  we  would 
tabulate  this  information  for  each  language  fragment. 

Two  computers  are  normally  compared  by  considering  their  ability  to 
perform  some  set  of  tasks  (a  benchmark) .  For  our  evaluations  we  choose 
the  set  of  tasks  to  be  the  anticipated  workload  of  the  machine  and  use 
the  set  of  sample  programs  discussed  in  Section  2.2  to  represent  the 
workload. 

The  next  step  is  to  relate  the  language  fragments  to  the  set  of 
sample  programs.  Assuming  that  the  cost  measure  contains  terms 
relating  to  both  the  static  (e.g.  ,  program  size)  and  dynamic  (e.g.,  number 
of  memory  references)  attributes  of  programs  we  need  to  know  the  number 
of  times  each  fragment  occurs  in  the  set  of  programs  (static  distribu¬ 
tion)  and  the  number  of  times  each  fragment  is  executed  when  the  pro¬ 
grams  are  executed  (dynamic  distribution) .  The  static  distribution  can 
be  obtained  by  running  the  sample  programs  through  a  compiler  which 
counts  fragments.  The  dynamic  distribution  is  a  different  matter.  For 
some  choices  of  cost  measures,  sample  programs,  and  computers  to 
be  compared,  the  dynamic  distribution  of  language  fragments  executed 
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will  change  from  computer  to  computer.  For  example,  one  computer 
might  use  more  bits  to  represent  floating  point  numbers  and  thereby 
cause  iterative  numerical  algorithms  to  converge  more  rapidly.  If 
this  situation  occurs,  separate  dynamic  distributions  will  have 
to  be  obtained  for  each  machine. 

The  information  we  require  to  evaluate  a  machine  is  related 
to  the  information  used  to  improve  its  design.  With  some  careful 
advance  planning,  information  required  for  design  evaluation  can 
be  gathered  during  design  improvement. 

Once  these  preliminaries  have  been  completed,  the  value  of 
the  cost  measure  for  each  computer  to  be  compared  can  be  calculated 
from  the  static  and  dynamic  distributions  of  language  fragment 
usage  and  the  tabulation  of  cost  measure  terms  associated  with 
each  language  fragment . 

Let  us  be  more  specific  in  the  case  of  a  simpler  linear  cost 
measure.  Assume  the  measure  has  the  form: 

M(P)  -  ?  „Cp)a 

i=l  i  i 

Where  the  a^'s  quantify  benefits  obtained  by  using  computer 

^  are  weighting  factors  based  on  the  cost  of  providing 

(P) 


and  the  u). 

1 


a^  on  computer  p.  For  the  summation  to  make  sense,  each  on  ^  a^ 
term  must  be  expressed  in  a  common  system  of  units  (usually  monetary) 


14 


Assume  the  programming  language  has  been  partitioned  into 
a  set  of  language  fragments  f_.  (1  <  j  <  m) .  Let  the  matrix 


be  defined: 


. . ^  =  quantity  of  benefit  a.  associated  with 


il 


language  fragment  f^  on  computer  p. 


The  vector  s_  is  defined  to  contain  the  static  distribution  of  language 
fragments  in  the  set  of  representative  programs: 


(P) 


Sj  =  static  frequency  of  language  fragment  f^ . 


The  vector  d_  r  is  defined  to  contain  the  dynamic  distribution 
of  language  fragments  when  the  set  of  sample  programs  are  executed 
on  computer  p: 

d_(P)  =  dynamic  frequency  of  language  fragment 
1  f  for  computer  p. 


If  we  order  the  terms  in  the  cost  measure  so  that  for  (1  <_  i  <_  k) 
the  terms  are  associated  with  static  characteristics  of  the  machine 
and  for  (k<  i  <  n)  the  terms  are  associated  with  dynamic  machine 


characteristics  then  the  cost  measure  can  be  written  as: 


m'P)  =  E  OJ.  (p)(™  q.(?L) 

i=1  i  -=1H i]  r 


2  W) 


i=k+l 


3  =  1 


il 


A  detailed  example  of  the  evaluation  process  using  a  linear  measure 
with  this  form  will  be  presented  in  Chapter  6. 
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2.4  A  Case  Study 

To  illustrate  our  experimental  improvement  and  evaluation  techniques 
in  concrete  terms  we  present  in  the  next  four  chapters  a  case  study  of 
language  directed  machine  design.  In  Chapter  3  we  describe  Student  PL, 
a  dialect  of  PL/I.  Chapter  4  contains  the  description  of  a  language 
directed  machine  which  implements  Student  PL.  In  Chapter  5  we  apply 
our  design  improvement  techniques  to  the  initial  machine  and  show  that 
it  is  possible  to  achieve  substantial  gains  in  machine  performance. 

We  conclude  the  case  study  in  Chapter  6  by  comparing  the  Student  PL 
machine  with  the  IBM  System/ 360. 

The  improvement  and  evaluation  phases  of  the  case  study  will 
require  a  cost  measure.  We  will  use  a  linear  measure  of  the  form 
discussed  in  Section  2.3.  The  terms  used  in  the  measure  were 
selected  because  they  are  representative  of  characterisitics 
of  machine  performance  which  have  historically  been  used 
to  evaluate  computers.  The  terms  in  the  measure  are: 

a^  the  number  of  bits  required  to  represent  instructions,'*' 

a^  the  number  of  bits  required  to  represent  data,'*' 

a^  the  number  of  memory  references  required  to  fetch 

instructions  during  program  execution, 

a^  the  number  of  memory  references  required  to  access 
(load  or  store)  data  during  program  execution, 

a^  the  number  of  bits  of  instruction  accessed  during 
program  execution 

a^  the  number  of  bits  of  data  accessed  during  program 
execution 


an  alternative  characterization  would  be  to  measure  memory  residency 
in  bit/seconds  during  program  execution;  however,  for  practical  reasons 
we  wished  to  avoid  terms  which  directly  involved  time. 
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We  will  discuss  the  weight  factors  used  in  the  measure  in 


Chapters  5  and  6. 
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Chapter  3  -  Student  PL 


3.1  Introduction 

Student  PL,  a  dialect  of  PL/I  [ANSI  1972]  was  designed  as 
a  test  vehicle  for  presenting  the  design  techniques  described  in  this 
thesis.  At  the  time  the  language  was  being  specified  [1966-67]  the  Stanford 
Computer  Science  Department  was  looking  for  a  successor  to  Burroughs 
B5500  Extended  Algol  as  a  teaching  language  for  introductory  programming 
courses.  We  designed  Student  PL  as  a  language  for  beginning  students 

in  an  attempt  to  solve  two  problems  simultaneously. 

PL/I  was  choosen  as  a  base  language  because  it  was  a  new  pro¬ 
gramming  language  which  had  not  then  been  the  subject  of  language  directed 
machines  and  because  the  character  string  handling  and  array  arithmetic 
facilities  in  PL/I  made  it  seem  like  an  improvement  over  Extended  Algol. 
Student  PL  is  a  dialect  rather  than  a  subset  of  PL/I  since  liberties 
were  taken  to  provide  alternatives  for  PL/I  constructs  which  we  felt 
were  inappropriate  for  beginning  students,  notably  formatted  input/ 
output  and  many  uses  of  the  GO  TO. 

In  the  rest  of  this  chapter  Student  PL  will  be  described  under  the 
assumption  that  the  reader  has  a  working  knowledge  of  PL/I. 

For  those  readers  who  prefer  to  understand  a  language  from  its  syntax,  a 
formal  grammar  for  Student  PL  is  given  in  Appendix  A.  In  later  chapters 
nonterminal  symbols  from  this  grammar  will  be  used  as  abbreviations  for 
language  constructs  (e.g.  <expression>  will  be  used  to  indicate  that  an 
arbitrary  expression  may  appear) .  In  this  chapter  we  concentrate  on  the 
semantics  of  Student  PL. 
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3.2  Data  Types,  Variables,  and  Scalar  Expressions 


Student  PL  includes  only  the  PL/I  data  types: 


FIXED  BINARY  (31,0) 

written  as  FIXED 

FLOAT  BINARY  (21) 

written  as  FLOAT 

BIT  (1) 

written  as  BIT 

CHARACTER  (4095)  VARYING 

written  as  CHARACTER 

LABEL 

written  as  LABEL 

The  PL/I  AUTOMATIC  storage  class  is  used  for  scalar  variables,  while 
all  arrays  are  in  CONTROLLED  storage.  Arrays  of  any  data  type  are 
allowed  with  no  limit  except  available  storage  on  number  of  dimensions 

Automatic  conversion  between  data  types  is  provided  as 
required,  during  the  evaluation  of  arithmetic,  relational  and 
string  expressions. 
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3.3  Array  Arithmetic 

Array  arithmetic  is  included  in  Student  PL,  however  the  definition 
of  array  assignment  differs  from  PL/I1.  In  assignment  statements 
involving  entire  arrays  the  expression  appearing  on  the  right  side  is 
completely  evaluated  before  any  assignment  is  made  to  elements  of 
arrays  appearing  on  the  left  side.  This  definition  produces  results 
identical  to  PL/I  if  elements  of  arrays  appearing  on  the  left  side  are 
not  used  on  the  right.  It  provides  a  saner  interpretation  for 
classical  PL/I  anomalies  like: 

A(*)  =  A(*)  /  A(I)  ; 

The  language  was  also  extended  to  permit  functions  to  have  array¬ 
valued  results.  A  builtin  function  ROW  was  provided  to  allow  the 
creation  of  vectors  and  arrays  from  expressions. 

Arrays  appearing  in  array  expressions  or  assignment  statements 
must  be  compatible.  PL/ I  requires  that  the  upper  and  lower  bounds  in 
corresponding  dimensions  be  the  same.  In  Student  PL  this  restriction 
was  eased  slightly.  Two  arrays  are  compatible  if  they  have  the  same 
number  of  dimensions  and  if  the  differences  between  upper  and  lower 
bounds  in  corresponding  dimensions  is  the  same.  Intuitively  the  two 
arrays  must  have  the  same  size  and  shape.  Using  the  Student  PL 
criterion,  arrays  declared:  A(5,  N:N+M)  and  B(0:4,  0:M)  would  be 
compatible.  Arrays  are  mapped  together  by  equivalencing  elements 
with  the  lowest  numerical  subscript  values.  In  the  example  above 
A(1,N)  is  used  with  B(0,0). 


1.  After  Student  PL  was  designed,  the  official  specification  of  PL/I 
was  changed  to  reflect  the  views  expressed  here  [MacLauren  1970]. 
(no  credit  claimed) 
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3.4  Programs,  Blocks,  and  Procedures 

A  program  in  Student  PL  consists  of  a  list  of  statements  (the 
body  of  a  procedure  with  option  MAIN) .  BEGIN-END  blocks  are 
available  to  delimit  the  scope  of  variables.  Proper  and  function 
procedures  allow  a  sequence  of  statements  to  be  executed  from  many 
places  in  a  program.  All  procedures  have  the  attribute  RECURSIVE. 

A  procedure  is  invoked  by  the  CALL  statement  or  by  its  use  as  a 
function  in  an  expression.  Exit  from  a  function  or  procedure  may 
be  made  using  the  RETURN  statement.  Actual  parameters  being  passed 
to  a  function  or  procedure  are  converted  (if  possible)  to  the  type 
of  the  corresponding  formal  parameter  when  the  function  or  procedure 
is  invoked.  Student  PL  does  not  include  PL/I  features  related  to 
multi-tasking. 
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3.5  Declarations  and  Storage  Management 

The  DECLARE  statement  allows  type  and  dimension  attributes  to 
be  specified  for  variables.  The  ENTRY  attribute  may  be  used  to 
declare  the  names  of  functions  and  procedures  so  that  they  may  be 
used  as  parameters  or  before  their  definitions  have  been  processed. 

The  type  of  a  function  may  be  declared  as  in: 

DECLARE  F  ENTRY  FIXED  ; 

instead  of  using  the  PL/I  RETURNS  attribute. 

Neither  explicit  array  bounds  nor  the  INITIAL  attribute  of  PL/I 
may  be  included  in  declarations  ;  hence,  declarations  are  strictly  non¬ 
executable.  These  restrictions  are  an  intentional  design  decision 
to  shield  the  student  from  the  often  unexpected  results  of  executing 
PL/I  declarations  as  well  as  avoiding  the  difficulty  of  describing  the 
semantics  in  all  situations. 

The  ALLOCATE  and  FREE  statements  may  be  used  to  explicitly  con¬ 
trol  the  allocation  of  storage  for  arrays. 


3.6  Assignment  Statements 

The  assignment  statement  provides  a  way  of  assigning  values  to 
scalar  and  array  variables.  The  multiple  assignment  statement  is 
allowed.  The  pseudovariab le  SUBSTR  may  be  used  on  the  left  side  of 
an  assignment  statement. 
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3.7  Input  and  Output 

The  PL/I  concept  of  the  pseudovariable  was  extended  to  provide 
convenient  free  format  input  and  output.  Each  reference  to  the 
pseudovariable  INPUT  retrieves  a  new  data  item  from  a  standard  data 
source.  An  assignment  to  the  pseudovariable  OUTPUT  has  the  side- 
effect  of  causing  the  value  assigned  to  be  printed.  The  builtin 
function  END_OF_DATA  can  be  used  to  detect  the  end  of  data  being 
input.  These  constructs  are  semantically  equivalent  to  the  PL/I 
GET  LIST,  PUT  LIST,  and  ON  ENDFILE  statements  which  they  replace. 

A  decision  was  made  not  to  provide  EDIT  I/O  or  formats  in  Student 
PL.  An  equivalent  effect  can  be  achieved  using  the  available 
character  string  operations  and  some  specially  provided  builtin 
functions . 

3.8  Builtin  Functions 

Table  3.8.1  lists  the  builtin  functions  available  in  Student  PL. 
Unless  otherwise  noted,  functions  with  the  same  name  as  functions 
defined  for  PL/I  have  the  same  semantics  in  the  context  of  the 
dialect.  Only  the  functions  ROW  and  UNDEFINED  may  have  array 
arguments 
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FUNCTION 

NAME 

FUNCTION 

TYPE 

ABS 

FIXED/ FLOAT 

ATAN 

FLOAT 

BIT 

BIT 

CHARACTER 

CHARACTER 

COS 

FLOAT 

DUMP 

E_F0RMAT 

CHARACTER 

END  0F_DATA 

BIT 

EXP 

FLOAT 

FIXED 

FIXED 

FLOAT 

FLOAT 

INDEX 

FIXED 

LENGTH 

FIXED 

LOG 

FLOAT 

MAX 

varies 

MIN 

varies 

MOD 

FIXED/ FLOAT 

RANDOM 

FLOAT 

SIGN 

FIXED 

SIN 

FLOAT 

SQRT 

FLOAT 

SUBSTR 

CHARACTER 

TAN 

FLOAT 

Table  3.8.1  Builti 


COMMENTS 
absolute  value 
arctangent 

forces  conversion  to  type  BIT 
forces  conversion  to  type  CHARACTER 
cosine 

produces  a  dump  of  all  variables 

produces  a  string  representing  the 
value  of  its  argument  in  scientific 
(E)  notation 

used  to  detect  end  of  input  data 

exponential  function 

forces  conversion  to  fixed  type 

forces  conversion  to  float  type 

location  of  second  argument  string 
in  first  argument  string 

length  of  a  character  string 

natural  logarithm 

maximum  of  arguments 

minimum  of  arguments 

first  argument  modulo  second  argument 

random  number  in  the  range  0.0- 1.0 

-1,-0  ,,1  depending  on  sign  of  argument 

sine 

square  root 

substring  (2  or  3  arguments) 
tangent 

Functions 
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FUNCTION 

NAME 


TIME 


UNDEFINED 


FUNCTION 

TYPE  COMMENTS 


FIXED  time  in  integer  hundredths  of 

second 


BIT 


true  if  argument  has  undefined 
value 


Table  3.8.1  Builtin  Functions  Ccont'd) 


3.9  Conditional  Statements 


Both  the  IF-THEN  and  the  IF-THEN-ELSE  forms  of  the  conditional 
statement  are  included  in  Student  PL.  A  conditional  statement  can 
appear  following  the  THEN  in  another  conditional  statement  only  if 
it  is  enclosed  in  DO-END  or  BEGIN-END  statement  brackets. 

3.10  GO  TO  Statement 

The  GO  TO  statement  allows  program  control  to  be  transfered  to 
a  statement  specified  by  a  label  constant  or  variable.  There  are 
restrictions  on  the  location  of  the  destination  statement.  In  place 
of  the  usual  limitation  against  jumping  into  BEGIN-END  blocks  and 
iterative  DO  groups,  a  more  general  and  slightly  more  stringent 
restriction  is  applied:  program  control  may  never  be  transfered 
into  a  compound  statement  structure  except  by  passing  through  the 
head  of  the  structure.  This  rule  prohibits  transfers  to  either 
statement  within  an  IF  statement  or  into  the  body  of  a  DO  WHILE 
group,  although  it  does  not  prevent  transfer  into  a  simple  DO-END 
group. 
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3.11  Groups 

Simple  DO-END  groups  allow  a  list  of  statements  to  be  treated 
as  one  statement.  The  DO  WHILE  group  permits  the  repetitive  execu¬ 
tion  of  a  list  of  statements  controlled  by  the  value  of  a  logical 
expression.  The  iterative  DO  group  with  control  variable  allows 
the  execution  of  a  list  of  statements  while  the  variable  takes  on 
a  sequence  of  values.  The  values  may  be  specified  either  by  a  triple 
consisting  of  an  initial  value  and  optional  step  and  limit  values  as 
in: 

DO  I  =  1  TO  10  BY  2; 

DO  I  =  0  TO  13; 

DO  I  =  23  BY  1; 
or  by  a  list  of  expressions: 

DO  I  =  1,2,3,5,7,11; 

or  by  any  combination  of  these  forms.  A  WHILE  clause  may  be  used  with 
the  iterative  DO. 

The  DO  CASE  group  [Hoare  1964]  allows  one  statement  to  be 
selected  for  execution  from  a  list  of  statements. 


3.12  Example 

Figure  3.12.1  contains  an  example  of  a  typical  program  in 
Student  PL. 
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/*  Program  to  bubble  sort  sequences 

of  character  strings  into 

ascending  order. 


*/ 

DECLARE  (i,  j,  k,  t,  limit)  FIXED, 
a C* )  CHARACTER; 

DO  WHILE  end  of  data  ; 

/*  Test  for  endfile  condition  */ 

limit  =  input; 

ALLOCATE  a (limit) ; 

/*  Read  in  sequence  length  */ 

/*  Storage  for  sequence  */ 

output  =  'Initial  sequence:'; 

DO  i  =  1  TO  limit; 

output, a (i)  =  input; 

END; 

/*  Read  and  list  sequence  */ 

i,j  =  limit; 

DO  WHILE  i  <=  j; 

j  =  -2; 

DO  k  =  2  TO  i; 
j  =  k  -  1; 

IF  a(j)  >  a(k)  THEN 

DO; 

t  =  a(j); 
a( j)  =  a(k) ; 
a(k)  =  t; 

i  =  j; 

END; 

END; 

END; 

/*  True  until  sequence  is  sorted  */ 

/*  Once  through  the  sequence  */ 

/*  Interchange  a(j)  and  a(k)  */ 

/*  Remember  index  of  last  swap  */ 

output  =  'Sorted  sequence:'; 
output  =  a(*) ; 

/*  List  sorted  sequence  */ 

FREE  a; 

/*  Release  storage  */ 

END; 

/*  of  DO  WHILE  loop  */ 

Figure  3.12.1  A  Student  PL  Program 
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CHAPTER  4 


The  Student  PL  Machine 

4.1  Introduction 

In  this  chapter  we  describe  a  language  directed  machine  to 
implement  Student  PL.  The  initial  machine  design  was  based  on 
our  intuition  and  experience  and  was  strongly  influenced  by  the 
machines  listed  in  Section  1.3.  We  have  tried  to  present  the 
design  of  the  machine  in  sufficient  detail  so  that  the  reader 
will  understand  and  appreciate  the  design  improvements  made  in 
Chapter  5.  At  the  same  time,  we  have  taken  the  liberty  of 

omitting  some  details  of  the  design  which  would  obscure 
our  discussion.  If  a  choice  had  to  be  made  between  a  reasonably 
accurate  prose  description  of  a  machine  function  and  a  tedious 
formal  definition  we  usually  opted  for  the  former. 

After  some  consideration  we  concluded  that  most  available 
notations  for  describing  computer  organizations  [Bell  and  Newell 
1971;  Chu  1971;  Knuth  and  McNeley  1964;  Dahl,  Myhehaug  and 
Nygaard  1968;  Schorr  1964]  were  unsuitable  for  our  purposes.  In 
most  cases  the  notation  would  have  forced  us  to  include  much  more 
detail  than  we  felt  was  appropriate  or  necessary.  We  therefore 
choose  to  create  a  Machine  Description  Language  (MDL)  to  describe 
the  Student  PL  Machine. 
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In  some  ways  MDL  resembles  the  programming  languages 
which  influenced  its  design.  Programs  are  composed  of  sequences 
of  statements  which  for  stylistic  reasons  each  start  on  a  new 
line.  Comments  enclosed  in  double  quotation  marks  (")  may  be 
interspersed  with  program  text.  Since  MDL  is  a  descriptive 
language,  indentation  and  paragraphing  are  used  to  indicate 
program  structure.  Consecutive  statements  indented  to  the  same 
level  are  treated  as  a  unit,  eliminating  the  need  for  explicit 
statement  brackets. 

The  basic  data  element  in  MDL  is  the  field,  a  collection  of 
contiguous  bits.  Fields,  which  may  be  of  any  width,  are  treated 
as  signed  integers  by  MDL  arithmetic  and  comparison  operators 
and  as  bit  strings  for  all  other  purposes.  The  representation 
choosen  for  negative  numbers  is  unimportant  here.  A  field  may 
be  a  scalar  field  that  is  indivisible,  or  a  structured  field 
that  contains  one  or  more  scalar  or  structured  fields.  Variab les 
may  be  declared  to  be  scalar  fields,  structured  fields,  or  single 
dimensional  arrays  of  scalar  or  structured  fields.  Each  subfield 
within  a  structured  field  must  be  given  an  explicit  name.  Dot 
notation  (as  in  PL/I)  is  used  to  indicate  reference  to  subfields. 
All  names  used  to  reference  subfields  are  fully  qualified  to 
avoid  ambiguity.  Square  brackets  ([])  are  used  to  indicate 
reference  to  an  element  of  an  array  variable. 

Field  declarations  in  MDL  associate  names  with  fields  and 
specify  the  size  and  structure  of  the  fields.  For  example: 
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field  x  (b  bit(10),  c  (d  bit(2) ,  e  bit(6))) 
specifies  the  field  named  x  contains  two  subfields  named  b 
and  c;  b  is  10  bits  wide;  and  c  contains  two  further  subfields 
d  and  e.  The  fields  in  x  are  refered  to  as  x.b,  x.c,  x.c.d, 
and  x. c.e. 

The  assignment  statement  in  MDL  indicates  the  movement  of 
information  from  one  field  to  another.  The  size  and  shape  of 
fields  involved  in  assignment  statements  must  match  exactly. 
Variables  appearing  in  assignment  statements  may  be  either  fields 
or  subfields.  Parentheses  are  used  to  simplify  two  common  special 
cases  of  field  assignment.  A  parenthesized  list  of  expressions 
appearing  on  the  right  side  of  an  assignment  statement  indicates 
a  concatenation  of  fields  to  form  a  structured  field.  The 
structure  of  the  field  must  be  completely  specified.  The  size  of 
each  subfield  will  be  determined  from  the  declaration  of  the 
variable  on  the  left  side  of  the  assignment  operator.  Thus: 
x  (5/2,  (j+1,  k [i ] ) ) 

assigns  a  value  to  the  structure  x  declared  above.  A  parenthesized 
list  of  variables  appearing  on  the  left  side  of  an  assignment 
statement  indicates  the  decomposition  of  a  field  into  subfields 
followed  by  an  assignment  of  the  subfields  values  to  the  listed 
variables.  The  assignment  of  fields  from  the  structure  x  to  the 
variables  p,q,r  would  be  written: 

(P,  (q,  r))  x 
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Symbol 

Meaning 

Example 

tl 

Delimits  MDL  comments 

•'Testing 

• 

Indicates  structure  subfields 

a.b 

y 

The  universal  separator 

a,b 

(  ) 

Delimit  list  of  expressions 
and  variables 

(a,b,3) 

{  } 

Delimit  unordered  sets  of  fields 

{a,  b,  3} 

I  ] 

Indicate  an  array  index 

a[i+l] 

<- 

Assignment  arrow 

a  b 

- 

Equality  relation 

3  =  a 

* 

Inequality  relation 

b  *  1 

> 

Greater  than  relation 

a  >  23 

< 

Less  than  relation 

c  <  43 

+ 

Binary  addition 

a  +  b 

- 

Arithmetic  negation 

Binary  subtraction 

-a 

a  -  b 

A 

Logical  and 

a  A  b 

V 

Logical  or 

a  V  b 

— 1 

Logical  complement 

— 1  a 

e 

Set  membership  relation 

3  e{ 1 ,  2, 

i 

Set  non -membership  relation 

3  HA,  5, 

Table  4.1.1  Single  Character  Symbols  in  MDL 
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The  left-side  structure  must  be  fully  specified.  Both  the 
if-then  and  if-then-else  form  of  conditional  statement  are  available 
in  MDL.  Program  paragraphing  is  used  to  resolve  the  ’’dangling 
else"  ambiguity.  A  while  statement  patterned  after  Algol  60 
provides  the  ability  to  repetitively  execute  a  sequence  of  statements. 
A  case  statement  allows  one  sequence  of  statements  to  be  selected 
for  execution  from  a  list  of  alternatives. 

Functions  and  procedures  in  MDL  provide  a  convenient  short¬ 
hand  for  expressing  commonly  used  sequences  of  MDL  statements. 

As  in  Algol  60,  the  call  of  a  procedure  is  a  statement.  All 
parameters  to  functions  and  procedures  are  passed  by  value.  The 
value  returned  by  a  function  is  indicated  by  an  assignment  to 
the  name  of  the  function.  Two  declarations  are  used  inside 
functions  and  procedures: 

parameter  A 
local  b 

to  declare  parameters  expected  by  the  function  or  procedure  and 
variables  local  to  it.  If  no  size  is  specified  for  local  variables, 
a  default  value  ("wide  enough")  is  assumed.  As  a  stylistic  con¬ 
vention,  we  will  use  capital  letters  to  name  parameters.  Some 
of  the  machine  instrucions  we  describe  require  additional 
information  (e.g.  an  operand  count);  we  will  refer  to  this 
information  as  an  argument  to  the  instruction.  The  declaration: 
argument  A 
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will  be  used  to  indicate  that  a  sequence  of  statements  expects 
this  information.  The  names  of  arguments  will  be  capitalized. 

In  the  following  sections  we  describe  the  structure  and 
instruction  set  of  the  Student  PL  Machine.  Examples  of  how 
typical  Student  PL  statements  ars  implemented  on  this  machine 
are  given  in  Appendix  B. 
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4.2  Storage 

In  this  section  we  describe  the  storage  areas  available  in 
the  Student  PL  Machine.  Each  area  will  be  given  a  mnemonic  name 
used  to  identify  it  in  the  MDL  instruction  descriptions  which 
follow.  For  storage  areas  which  are  stacks,  a  pointer  to  the 
top  element  in  the  stack  will  also  be  defined. 

In  designing  a  memory  system  for  the  Student  PL  Machine  we 
distinguished  two  classes  of  storage  allocation.  Synchronous  storage 
has  the  property  that  storage  requests  nest  properly  in  time,  that 
is,  the  most  recently  allocated  storage  is  the  first  to  be  released. 
The  storage  of  variables  local  to  Student  PL  blocks  and  procedures 
is  synchronous.  Stacks  [Knuth  1968,  Section  2.2]  provide  a 
convenient  way  to  manage  storage  with  this  nesting  property,  and 
were  used  whenever  synchronous  storage  allocation  was  required. 
Asynchronous  storage  allocation  can  occur  at  arbitrary  times 
during  the  execution  of  a  program,  for  example  the  allocation  and 
freeing  of  PL/I  controlled  storage.  Our  uniform  solution  for 
asynchronous  storage  allocation  was  to  provide  separate  storage 
areas  to  satisfy  asynchronous  storage  requests. 

The  storage  areas  used  in  the  Student  PL  Machine  are  described 
in  Figure  4.2.1. 

A  major  decision  in  the  design  of  the  machine  was  to  use 
typed  data.  Each  data  value  has  associated  with  it  a  type  field 
which  describes  the  interpretation  appropriate  for  the  value 
(e.g.,  integer,  floating  point  number,  descriptor,  etc.).  The 
simple  types  recognized  by  the  machine  are  listed  in  Table  4.2.1. 
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Figure  4.2.1  Student  PL  Machine  Storage  Areas 


Scalar  Type 

Denotes  a: 

fixed 

fixed  point  number 

float 

floating  point  number 

bit 

bit  value 

char 

character  string  descriptor 

labc 

label  constant  descriptor 

labv 

label  variable  descriptor 

star 

*  used  as  an  array  subscript 

ind 

indirect  address  descriptor 

arlm 

array  element  descriptor 

prog 

program  segment  descriptor 

Composite  Types 

at  =  {fixed,  float}  Arithmetic  Type 

dt  =  {bit,  fixed,  float,  char}  Data  Type 

Table  4.2.1  Simple  and  Composite  types 
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For  notational  convenience  two  composite  types:  arithmetic  type 
and  data  type  are  also  defined. 

The  data  stack  (ds)  is  used  to  hold  variables  and  constants 
local  to  currently  active  procedures  and  to  hold  intermediate 
results  during  expression  evaluation.  Storage  for  each  constant 
is  allocated  in  the  local  storage  of  the  outermost  procedure  which 
contains  a  use  of  the  constant.  A  procedure  nested  inside  the  outer 
procedure  uses  the  global  copy  of  the  constant.  Any  space  not 
used  for  local  storage  is  used  to  store  array  elements .  The 

fields  and  subfields  which  comprise  an  entry  is  ds  are  defined  in 
Figure  4.2.2a.  The  MDL  definition  of  ds  is  given  in  Figure  4.2.2b. 

We  express  the  number  of  elements  in  ds  symbolically  as  ds_size 
since  our  discussion  does  not  depend  on  the  size  of  ds.  The  widths 
choosen  for  the  fields  in  ds  correspond  to  those  used  in  the  simulation 
of  the  Student  PL  Machine  described  in  Chapter  5.  Other  field 
widths  could  be  used  as  long  as  the  information  required  for 
machine  operation  would  still  fit. 
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Data  Stack  -  ds 


ds 

ds .  t 

ds  v 

T 

1  ds  .  t .  s 

ds .  v.  a 

ds.v.b 

1  1  ^"ds.t.a 
1  ds  .  t  .p 
— -  ds  .  t .  u 


dsp 


a)  Subfields: 

ds.t  Type  information  field 


ds.t.u 

ds .  t .  p 


ds .  t.  a 

ds .  t .  s 
ds .  v 
ds .  v.  a 


Undefined  type  bit,  ds.t.u  =  1  if  value  of 
corresponding  ds.v  field  is  undefined 

Procedure  bit,  ds.t.p  =  1  indicates  the 
corresponding  ds.v  field  contains  the 
descriptor  for  a  proper  or  function 
procedure 

Array  bit,  ds.t. a  =  1  means  that  the  ds.v.b 

field  contains  a  pointer  to  an  array  descriptor 

Simple  type,  see  Table  4.2.1  for  possible  values 

Value  field.  Type  of  value  despends  on  ds.t 

Field  a  for  descriptors 


ds.v.b  Field  b  for  descriptors 


b)  MDL  Declaration 

field  (0 : dsjsize)  ds  Ct  C  u  bit(l) ,  p  bit(l),  a  bit(l),  s  bit(4)) 

v  C  a  bit(12),  b  bit(20)) 


field  dsp  bitCl6)  "pointer  to  top  of  ds" 


Figure  4,2.2  The  Data  Stack  -  ds 
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Descriptors  are  used  to  access  data  items  which  are  too  large 
to  fit  in  one  ds  entry.  Character  strings  and  program  segments 
(sequences  of  machine  instructions)  are  stored  in  string-segment 
memory  (ssm) .  Information  required  to  access  array  elements  is 
stored  in  the  array  descriptor  table  (adt,  Figure  4.2.3).  The 
descriptors  used  in  the  machine  are  described  in  Table  4.2.4. 

The  scope  stack  (ss)  and  the  display  are  used  to  maintain 
the  addressability  of  variables  and  constants  during  program 
execution.  An  entry  is  made  in  the  scope  stack  each  time  a  block 
or  procedure  is  entered.  The  fields  in  ss  (Figure  4.2.5) 
contained  information  required  to  restore  the  address  environment 
existing  before  the  block  or  procedure  was  entered.  The  display 
contains  only  pointers  to  ss. 

The  Scope  Table  (set,  Figure  4.2.6)  and  the  Symbol  Table 
(syt.  Figure  4.2.7)  contain  static  information  describing  blocks 
and  procedures  (set),  and  variables  (syt)  occurring  in  a  program. 
This  information  is  used  to  initialize  type  fields  in  ds,  when  a 
new  scope  is  entered  and  to  check  the  type  of  parameters  being 
passed  to  procedures. 
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a)  one  dimensional  array 


b 

n  C=l) 

1 

lbi 

ub, 

1 

mi 

b)  two  dimensional  array 


b 

n  (=2) 

1 

ibi 

ub^ 

ml 

lb2 

ub 

2 

m2 

Where: 

adt  .n 
adt  .b 


adt .  1 


adt.  lb[i] 
adt.  ub  [i] 
adt.  m[i] 


dimensionality  of  the  array 

address  of  array  element  with 
least  subscript  values  (e.g. 
a(lb  )  or  a ( lb  ,  lb  ) ) 
relative  to  start  ox  data  stack 

address  of  array  descriptor  table 
entry  for  previous  allocation 
of  the  array  if  one  exists 
otherwise  -1 

lower  bound  in  the  ith  dimension 

upper  bound  in  the  ith  dimension 

multiplier  used  to  calculate  span 
between  elements  in  the  ith  dimension. 


Figure  4.2.3.  Array  Descriptors 
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Descriptor 


character 

string 


indirect 

address 


program 

segment 


label 


array 

pointer 


array 

element 


Indicated  by:  Definition 

ds  .  t .  u  =  0  and 


ds.t.s  =  char 


ds.t.s  =  ind 


(ds.t.s  =  prog 
or 


ds  .  t .  p  =  1 ) 


(ds.t.s  =  labc 
or 

ds.t.s  =  labv) 


ds  .  t .  a  =  1 


ds.t.s  =  arlm 


ds  .  v .  a 
ds .  v.b 


ds . v. a 
ds .  v .  b 


ds . v. a 


ds  .  v .  b 


ds .  v .  a 


ds . v.b 


ds . v.b 


ds  .  v .  a 


ds  .  v .  b 


length  of  string  in  characters 

address  of  first  character 
of  string  in  string-segment 
memory 

index  into  scope  stack 

offset  from  start  of  ds 
storage  for  containing  scope 
Item  being  referenced  is  in 
the  ds  entry  given  by: 

ss[ds.v.a]  +  ds.v.b 

length  of  program  segment  in 
syllables 

address  of  segment's  first 
syllable  in  string-segment 
memory 

relative  address  of  labelled 
instruction  within  program 
segment 

address  of  first  instruction 
syllable  of  containing  segment 
in  string-segment  memory 

index  of  descriptor  for  the 
array  in  the  array  descriptor 
table 

index  of  descriptor  of  array 
in  array  descriptor  table 

offset  of  array  element  from 
first  element  of  the  array 


Table  4.2.4 


Student  PL  Machine  Descriptors 


Scope  Stack  -  ss 


ss 

ss.n 

ss .  1 

ss.d 

ss  .p 

ss  .w 

<-Ssp 


aj 


b) 


Subfields : 
ss.n 
ss .  1 

ss .  d 
ss  .p 
ss  .w 

MDL  declaration 


Index  into  Scope  Table 

Static  link  used  to  chain  ss  entries 
together 

Value  of  dsp  when  scope  was  entered 
Value  of  psp  when  scope  was  entered 
Value  of  lr  when  scope  was  entered 


field  (0:ss_size)  ss  (  n  bitC8),  1  bit(8),  d  bit(16), 

p  bit(8)  ,  w  bit C 12) ) 

field  ssp  bit(6)  "pointer  to  top  of  ss" 

Figure  4.2.5  Scope  Stack  -  ss 
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Scope  Table 


set 


set 

set  .s 

set .  c 

set  .p 

set .  1 

a)  Subfields 


set.  s 

location  of  first  syt  entry 
for  this  scope 

set .  c 

number  of  syt  entries  for 
this  scope 

set  .p 

number  of  parameters  allowed 
for  this  scope 

set .  1 

the  lexical  level  of  the  scope 

b)  MDL  desclaration 

field  (T):sct_size)  set  (s  bit(8),  c  bit(8) ,  p  bit(8),  1  bit(4)) 


Figure  4.2.6  The  Scope  Table  -  set 
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Symbol  Tahle  -  syt 


syt 

svt.n 

§yt..c _ 

syt.  t 

syt.v 

a) 


b) 


Sub fie Ids 

syt  .n 

printable  name  of  the  variable 
(used  for  error  messages) 

syt .  c 

subscript  count  for  array  variables 

syt .  t 

type  of  the  variable 

syt.v 

initial  value  for  constants 

MDL  Definition 

field  (0  :syt  size)  syt  Cn  bitC256)  ,  c  bit(8) ,  t  bit(8) ,  vbit(32)) 


Figure  4.2.7  The  Symbol  Table  -  syt 
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Program  Segment  Stack.  -  ps 


ps 

ps.  1 

ps .  a 

ps .  r 

Ps.d _ 

psp 


a)  Sub  fie  Ids 
ps .  1 
ps .  a 

ps .  r 


b) 


ps .  d 

MDL  Definition 


Length  of  program  segment  in  syllables 

Address  of  segment's  first  instruction 
in  string-segment  storage 

Relative  address  of  next  instruction  to 
be  executed  within  segment 

Value  of  dsp  when  ps  entry  was  made 


field  (0:ps_size)  pS  (_1  bit(12),  a  bit(20),  r  bit(13), 

d  bit C16) ) 


field  psp  bitC16)  "pointer  to  top  of  ps" 


Figure  4.2.8  Program  Segment  Stack  -  ps 
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The  basic  machine  instruction  is  the  instruction  syllable. 

Program  segments  are  sequences  of  instruction  syllables  stored 
in  string-segment  memory.  Program  segment  descriptors  (Table  4.2.4) 
are  used  to  access  program  segments.  The  Program  Segment  Stack 
Cps)  (Figure  4.2.8)  is  used  to  control  the  sequencing  of  program 
segment  execution.  The  top  entry  in  ps  points  to  the  instruction 
and  segment  currently  being  executed.  A  segment  is  placed  in 
execution  by  pushing  its  descriptor  onto  ps .  Execution  of  a  segment 
ends  when  its  descriptor  is  removed  from  the  top  of  ps.  The 
machine  instruction  execution  cycle  is  described  in  Figure  4.2.9. 

One  additional  piece  of  storage  the  line  register  (lr)  is  used  to 
keep  track  of  the  source  program  line  number  corresponding  to  the 
instruction  currently  being  executed.  It  is  used  only  in  the  production 
of  error  messages.. 
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field  op  bitC8)  "Instruction  Code" 

while  executing  do 

while  psjpspj.r  >  psjpsp] . 1  do 

popps  "run  off  end  of  segment" 
op  segmemjpslpsp] . a  +  psjpspj.r]  "instruction  code" 
ps  Jpspj  .r<-ps[psp]  .r  +  lengthCop)  "update  program  counter" 
case  op  of 


"execute  instruction  specified  by  op" 


Figure  4.2.9  Instruction  Fetch  and  Execution 


Note:  the  auxilliary  procedure  popps  is  defined  in  Table  4.5.2 
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4.3  Data  Access  and  Addressing 

Data  access  instructions  are  used  to  fetch  the  values  of 
variables  and  constants  to  the  top  of  ds  and  to  assign  a  value  to 
a  variable  from  the  top  of  ds.  Addressing  of  constants  and  variables 
in  the  machine  is  based  on  the  address  couple,  [Anderson  1961;  Randell 
and  Russell  1964;]  a  lexical  level-order  number  pair.  Each  block 
or  procedure  is  assigned  a  lexical  level  depending  on  its  depth 
of  static  nesting  in  the  program.  Order  numbers  are  assigned  to 
constants  and  variables  occurring  in  a  scope  based  on  order  of 
appearance . 

To  access  a  variable  or  constant  its  address  couple  must  first 
be  transformed  into  an  indirect  address  descriptor  which  points  at 
the  appropriate  entry  in  ds.  The  SHORT  NAME  (lexical  level  0-3, 
order  number  0-15)  and  LONG  NAME  (lexcial  level  0-15,  order  number 
0-4095)  instructions  (Table  4.3.1)  perform  this  transformation. 

The  definitions  of  these  two  instruction  has  been  combined  since 
the  only  difference  between  them  is  the  encoding  of  the  address 
couple . 

Once  an  indirect  address  descriptor  has  been  created,  an 
EVAL  instruction  (Table  4.3.1)  is  used  to  bring  the  value  to  the  top 
of  ds.  An  error  is  signalled  if  the  value  has  undefined  type. 

The  SUBS  instruction  (Table  4.3.1)  is  used  to  process  subscripted 
references  to  array  variables.  The  result  of  this  instruction  is 
either  an  array  element  descriptor  pointing  at  a  single  element  of  the 
array,  or  a  pointer  to  a  descriptor  for  a  sub array  of  the  original 
array.  The  instruction  bounds  checks  all  subscripts. 
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The  STORE  instruction  (Table  4.3.1)  performs  the  action 
required  to  implement  Student  PL  assignment  statements  including 
array'  assignments.  Tire  POP  instruction  is  used  to  delete  tire  value 
of  the  right  side  expression  of  an  assignment  statement  from  ds 
after  all  assignments  have  been  made. 

Auxiliary  procedures  used  in  the  description  of  the  data 
accessing  instructions  are'  defined  in  Table  4.3.2. 

Figure  B.l  in  Appendix  B  illustrates  the  use  of  instructions 
described  in  this  section  in  a  multiple  assignment  statement. 
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Instruction 

Definition 

SHORT  NAME 
LONG  NAME 

argument  A  Man  address  couple" 
local  p,q,a 

(p,  q)  A  "lexical  level,  order  number" 

a  ss  [display  [p]]  .d  +  q 

pushds 

if  ds[a].t.s  =  ind  then 

ds  [dsp]  <-  ds  [a]  "shorten  indirect  chain" 

else 

ds  [dsp]  .  t  (0,  0,  0,  ind) 

ds[dsp].v  (display [p],  q) 

EVAL 

local  a 
a  chain  (dsp) 

ds[dsp]  +■  ds[a] 
if  ds[dsp].t.u  =  1  then 

error  "use  of  undefined  value" 

SUBS 

argument  N  "count  of  subscripts  being  applied" 

local  a 

a  +-  chain(dsp  -  N)  "locate  variable" 

if  ds  [a]  .  t .  a  4  1  then 

error  "attempt  to  subscript  non  array" 

ds[dsp-N]  ■*-  subscript(ds  [a]  .v.b,  N) 
dsp  <-  dsp  -  N 

STORE 

local  a 

a  chain(dsp-l) 

if  ds[a].t.a  =  1  then  "array  on  left" 

if  ds[dsp].t.a  =  0  then  "scalar  on  right" 

array  fill(ds[a],  convert (ds [dsp] ,  ds[a].t.s)) 

else  "array  on  right" 

array  copy(ds[a],  ds[dsp]) 

else 

ds  [a] .  t .u  0 

ds[a].v«-  convert  (ds  [dsp] ,  ds[a].t.s) 
ds[dsp-l]  <-  ds  [dsp] 
popds 

POP 

popds 

Table  4.3.1  Data  Access  Instructions 
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Procedure 


Definition 


pushds 

popds 

chain 


error 

subscript 


array  fill 


Table  4. 


dsp  ■*-  dsp  +  1 

if  dsp  >  ds_size  then 

error  "data  stack  overflow" 

dsp  ■**  dsp  -  1 
if  dsp  <  0  then 

error  "data  stack  underflow" 

parameter  P  "pointer  to  ds  entry" 

"used  to-  follow  indirection  chains" 
local  x 
x  P 

if  ds[x].t.s  =  ind  then  "indirect  descriptor" 
x  ss  [display  [ds  [x]  .v. a]]  .d  +  ds[x].v.b 
if  ds[x].t.s  =  arlm  then  "array  element  descriptor" 
x  adt  [ds  [x]  .  v.  a] .  a  +  ds[x].v.b 
chain  +-  x 

"used  to  signal  execution  errors" 

parameter  P  "index  of  array  descriptor  in  adt" 
parameter  N  "number  of  subscripts  being  applied" 

"Processes  a  subscripted  array  reference: 

1)  Check  for  correct  dimensionality  (adt[P].n  =  N?) , 

2)  Converts  each  numeric  subscript  to  type  fixed 
(if  required)  and  checks  it  against  the 
upper  and  lower  bounds  in  adt, 

3)  if  one  or  more  subscripts  was  a  '  *',  create 
a  descriptor  for  the  specified  subarray 

in  adt  and  return  a  pointer  to  it.  Algorithm 
for  creating  subarray  descriptor  is  described 
in  [Becker  1968] , 

4)  Otherwise  calculate  the  address  of  a  single 
array  element  and  return  an  array  element 
descriptor  which  points  at  it.  Address 
calculation  algorithm  is  given  in  [Gries 

1971,  p.  176-180]" 

parameter  D  "ds  entry  containing  array  descriptor 
pointer" 

parameter  V  "ds  entry  containing  a  scalar  value" 

"Sets  each  element  of  the  array  pointed  at  by  D 
to  the  value  contained  in  V" 


3.2  Auxiliary  Procedures 
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Procedure 

Definition 

array  copy 

parameter  D  "ds  entry  containing  array  descriptor  pointer7' 
parameter  V  "ds  entry  containing  array  descriptor  pointer" 

"Check  the  arrays  pointed  at  by  D  and  V  for  compatabi lity , 
creates  a  temporary  array  and  copies  the  elements  of  the 
array  pointed  at  by  V  into  it.  Changes  the  array  des¬ 
criptor  pointed  at  by  D  to  reference  the  temporary  array 
(modifies  adt.b)" 

convert 

parameter  D  "an  entry  in  ds" 

parameter  S  "a  scalar  type" 

"converts  ds  entry  D  so  that  the  value  field 
is  of  scalar  type  S.  Returns  D  appropriately 
modified.  An  error  is  signalled  if  the  con¬ 
version  requested  is  illegal  in  Student  PL" 

Table  4.3.2 

(cont . ) 
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4.4  Instructions  for  Infix  and  Prefix  Operators 

Machine  instructions  described  in  this  section  implement 
the  infix  and  prefix  operators  of  Student  PL  (+,  *,  <=,  ||,  etc.) 

For  brevity  the  instructions  are  defined  only  for  scalar  operands; 
the  extensions  required  to  process  array  operands  are  described 
in  Figure  4.4.1. 

In  the  description  of  the  Student  PL  machine  a  distinction 
is  made  between  arithmetic  done  between  MDL  fields  and  arithmetic 
done  between  values  known  to  the  Student  PL  program.  Rather  than 
add  a  large  number  of  arithmetic  functions  or  operators  to  MDL, 
we  choose  to  represent  Student  PL  data  manipulation  operations 
with  the  operator  functions  8^  and  defined  in  Tables  4.4.1  and 
4.4.2.  The  superscript  p  specifies  the  data  type  common  to  the 
Student  PL  operands;  the  subscript  q  selects  the  operation  to  be 
performed.  The  value  of  0^  and  <j>^  are  MDL  operators  which  perform 
the  operation  specified  on  operands  of  the  specified  type. 

The  implementation  of  typical  arithmetic  expression  is 
illustrated  in  Figure  B2. 
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if  ds[dsp].t.a  =  OA  ds  [dsp-lj  .  t.a  =  0  then 
"scalar  *■  scalar  op  scalar" 


else 

"create  temporary  array  to  hold  result" 

if  ds[dsp].t.a  =  1  \  ds [dsp-1] . t . a  =  1  then 
"array  ■*"  array  op  array" 

"perforin  scalar  semantics  between  corresponding 
array  elements.  Results  put  in  temporary  array" 

else  if  ds[dsp].t.a  =  1  then 
"array  scalar  op  array" 

"perform  scalar  semantics  between  scalar  operand 
and  each  element  of  array  operand.  Put  results 
in  temporary  array" 


else 

"array  array  op  scalar" 

"see  previous  case" 

"set  ds [dsp-1]  to  point  at  descriptor  for  temporary 
array" 

popds 


Figure  4.4.1  Extension  of  Infix  Operator  Instructions  to 
Array  Operands 
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CD  Hd 


\p 

Type  of  Operands 

bit 

fixed 

float 

char 

ADD 

addition 

addition 

SUB 

subtraction 

subtraction 

MUL 

multiplication 

multiplication 

DIV 

division 

division 

PWR1 

Note  1 

Note  2 

pwr2 

Note  3 

LT 

less  than 
comparison 

less  than 
comparison 

less  than 

comparison4 

GT 

greater  than 
comparison 

greater  than 
comparison 

greater  than 
comparison  4 

LE 

less  than  or 
equal 

comparison 

less  than  or 
equal 

comparison 

less  than  or 
equal 
comparison  ^ 

GE 

greater  than  or 
equal 

comparison 

greater  than  or 
equal 

comparison 

greater  than  or 

equal 

d 

comparison4 

EQ 

equality 

comparison 

equality 

comparison 

equality 

comparison 

equality 

comparison 

NE 

inequality 

comparison 

inequality 

comparison 

inequality 
t comparison 

inequality 

comparison 

AND 

logical 

conjunction 

OR 

logical 

disjunction 

Note  1.  fixed  point  number  raised  to  a  fixed  point  power 
Note  2.  floating  point  number  raised  to  a  fixed  point  power 
Note  3.  floating  point  number  raised  to  a  floating  point  power 
Note  4.  lexe graphical  ordering  of  character  strings  using  the  PL/ I  rules 
for  string  comparison 

Table  4.4.1  The  Operator  Function  0^ 

H 
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p 


bit 


fixed 


float 


NEG 


NOT 


arithmetic 

negation 

arithmetic 

negation 

logical 

complement 

Table  4.4.2  The  Operator  Function  <j>P 
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Table  4.4.3  gives  the  definition  of  the  instructions  used  to 
implement  unary  and  binary  arithmetic,  relational,  logical,  and 
string  operators  in  Student  PL.  The  instructions  implementing 
binary  operators  have  two  operands  ds [dsp]  and  ds[dsp-l].  The 
operands  are  deleted  from  ds  and  the  result  of  the  operation  placed 
on  top  of  ds .  Instructions  for  unary  operators  work  on  the  top 
entry  in  ds .  The  auxiliary  MDL  procedures  used  to  implement 
these  instructions  are  listed  in  Table  4.4.4. 
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Ins  true ti on 

ADD 

SUB 

MUL 

DIV 

PWR 


CAT 


LT 

GT 

LE 

GE 

EQ 

NE 

AND 

OR 


PLUS 

NEG 


NOT 


Table  4.4.3 


Definition  for  scalar  operands  ds[dsp]  and  ds[dsp-l] 


local  p 

p  setup  (at,  dsp,  dsp-1) 

ds[dsp-l]  (p,  ds [dsp-1]. v  0P  ds[dsp].v) 
popds  op 


local  p,  q 

p  type  (ds  [dsp]  .t,  ds  [dsp-1].  t,  at) 
q  ■<-  type(ds[dsp]  .  t,  fixed,  at)  "exponent  type" 
ds  [dsp]  convert(ds  [dsp-1]  ,  p) 


ds  [dsp-1]  «-  (p, 
popds 


ds  [dsp-1] .  v  6P  , 
r  exmap  (q) 


ds [dsp] . v) 


local  p,  q 

force_type(char,  dsp,  dsp-1) 

q  ds[dsp].v.a  +  ds  [dsp-1] .  v.  a  "sum  operand  lengths" 

p  string_space(q)  "obtain  space  for  result" 

move(ds [dsp-1] .v,  p)  "copy  first  operand" 

move (ds [dsp] .v,  p+ds [dsp-1] .v. a)  "copy  second  operand" 

ds  [dsp-1]  .v  (q,  p)  "create  descriptor  for  result" 

popds 


local  p 

p  <-  setup(dt,  dsp,  dsp-1) 

ds  [dsp-1]  -Kbit,  ds  [dsp-1].  v  0P^  ds[dsp].v) 
popds 


force_type(bit ,  dsp,  dsp-1)  ,  . 

ds  [dsp-1]  (bit,  ds  [dsp-1],  v  0  1  ds[dsp].v) 

popds  '  °P 

setupl (dsp) 


setupl(dsp) 
ds  [dsp]  .  v  tj) 


ds [dsp] . t.s 
op 


ds [dsp] .  v 


ds  [dsp]  convert  (ds  [dsp]  ,  bit) 
ds  [dsp]  .v  ds  [dsp]  .v 


Infix  and  Prefix  Operator  Instructions 
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Procedure 

Definition 

force  type 

parameter  S  "a  scalar  type" 

parameter  A  "index  of  an  entry  in  ds" 

parameter  B  "index  of  an  entry  in  ds" 

ds  [A]  +■  convert (ds [A] ,  S) 
ds[B]  ■«-  convert (ds [B]  ,  S) 

type 

parameter  A  "a  scalar  type" 

parameter  B  "a  scalar  type" 

parameter  S  "a  set  of  scalar  types" 

"scalar  types  are  assumed  to  be  ordered: 

bit  <  fixed  <  float  <  character  <  undef" 
if  A  <  B  then 
type  <-  B 
else 

type  A 

if  type  £  S  then 

error  "illegal  operand  type" 

setup 

parameter  S  "a  set  of  scalar  types" 

parameter  A  "index  of  an  entry  in  ds" 

parameter  B  "index  of  an  entry  in  ds" 

local  p 

p  type(ds [A] .t ,  ds[B].t,  S) 

force  type(p,  A,  B) 
setup  p 

setupl 

parameter  A  "index  of  an  entry  in  ds" 
local  p 

p  type(ds  [A]  .  t,  fixed,  at) 

ds  [A]  «-  convert  (ds  [A]  ,  p) 
setupl’  -t-  p 

string  space 

parameter  N  "number  of  characters  required" 
"returns  the  starting  address  of  an  N  character 
hole  in  string-segment  memory.  May  cause 
compaction  of  string-segment  memory." 

move 

parameter  D  "a  character  string  descriptor" 
parameter  A  "an  address  in  string-segment  memory" 
"move  the  string  described  by  D  to  a  new  location 
in  string- segment  memory  starting  at  address  A" 

exmap 

parameter  P  "a  scalar  type  -  fixed  or  float" 

"see  PWR  instruction  and  definition  of  6" 
if  P  =  fixed  then 
exmap  PWR^ 

else 

exmap  +■  PWR? 

Table  4.4.4 

Auxiliary  Procedures 
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4.5  Sequencing  and  Control 

An  object  program  resulting  from  the  translation  of  a  Student 
PL  program  consists  of  a  number  of  program  segments.  These 
segments  represent  a  division  of  the  program  into  "natural"  pieces 
(e.g.  the  body  of  a  group,  an  alternative  in  an  IF  statement,  the 
body  of  a  block  or  procedure,  etc.).  A  segment  is  placed  into 
execution  when  the  CALL  instruction  (Table  4.5.1)  pushes  its 
descriptor  onto  the  program  segment  stack  (ps) .  Execution  of  a 
segment  terminates  when  the  flow  of  execution  runs  off  the  end  of 
the  segment  (see  Figure  4.2.9)  or  when  ps  is  explicitly  popped  by 
the  CRET  instruction  (Table  4.5.1).  The  CYCLE  instrucion  is  used 
to  cause  the  repeated  execution  of  a  segment. 

The  DOSTORE,  DOTEST,  and  DOINCR  instructions  (Table  4.5.1) 
implement  the  initialization,  testing  and  incrementation  of 
iterative  DO  groups  (see  Figures  B.5  -  B.7).  The  GOTO  instruction 
implements  the  GOTO  statement. 

The  display_update  procedure  will  be  described  in  Section  4.6. 
The  other  procedures  needed  to  implement  the  sequencing  instructions 
are  given  in  Table  4.5.2. 
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Instruction 


CALL 

CRET 


CYCLE 

DOSTORE 

DOTEST 


Table  4.5. 


Semantics 

if  ds[dsp].t.s  i  prog  then 

error  "attempt  to  execute  non-program" 

pushps  "load  program  stack" 

ps  [psp]  •*-  (ds  [dsp] .  v.  a,  ds[dsp].v.b,  0,  dsp-1) 
popds 

ds[dsp]  convert (ds [dsp] ,  bit) 
if  ds  [dsp]  .v  then 

popds  "continue  executing  current 

segment" 

else 

popds 

popps  "terminate  current  segment's 

execution" 

ps  [psp]  .r  «-  0  "reset  relative  address" 
local  a 

a  chain  (dsp-1)  "address  of  loop  variable" 
ds[a]  convert (ds [dsp] ,  ds[a].t.s) 
ds  [a]  .  t  .u  +■  0 
popds 

local  a 

a  +-  chain (dsp-2)  "address  of  loop  variable" 
ds  [dsp-1]  convert  (ds  [dsp-1] ,  ds[a].t.s) 
pushds 

if  ds [dsp-2]. v  <  0  then  "test  sign  of  increment" 


ds[dsp]  (bit,  ds[a].v 

ds  [a] .  t .  s 
0GE 

ds [dsp-1] . v) 

else 

Qds [a] . t.s 
6LE 

ds  [dsp]  (bit,  ds[a].v 

ds  [dsp-1] .  v) 

1  Sequencing  and  Control  Instructions 
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Instruction 

Semantics 

DOINCR 

local  a 

a  chain (dsp-2)  "address  of  loop  variable" 

ds[dsp]  convert  (ds  [dsp] ,  ds[a].t.s) 

ds[a].v«-  ds[a].v  6^pa^‘t'S  ds[dsp].v 

GOTO 

local  a,b 
b  ■«-  ssp 

a  <•  chain(dsp)  "address  of  label  descriptor" 

ssp  ds[dsp].v.a  "reset  ssp  from  indirect 

descriptor" 

while  ds[dsp].v.b  t  ps[psp].a  do 
psp  <-  psp  -  1 
if  psp  £  ss[ssp].p  then 

error  "destination  label  not  in  active 

segment" 

ps[psp].r-<-  ds[a].v.a  "set  relative  address  in 

segment" 

dsp  ps[psp].d  "reset  dsp" 

if  ssp  i  b  then  "reset  the  display  if  needed" 
display  update 

Table  4.5.1  Sequencing  and  Control  Instruction  (cont.) 
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Procedure 

Definition 

pushps 

psp  psp  +  1 

if  psp  >  ps  size  then 

error  "program  segment  stack  overflow" 

popps 

psp  +-  psp  -  1 
if  psp  <  0  then 

error  "program  segment  stack  underflow" 

Table  4.5.2  Auxiliary  Procedures 
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4.6  Block  and  Procedure  Instructions 


The  machine  instructions  required  to  implement  BEGIN-END  blocks 
and  procedures  (scopes)  are  given  in  Table  4.6.1.  The  ENTER 
instruction  is  used  to  activate  a  scope.  The  END  instruction  performs 
the  inverse  operation  of  terminating  the  execution  of  a  scope.  The 
PARAM  instruction  does  type  checking  for  procedure  parameters,  while 
the  LFUNC  instruction  provides  a  linkage  to  pseudo-functions  which 
occur  on  the  left  side  of  assignment  statements. 

The  auxiliary  functions  required  to  implement  these  instructions 
are  described  in  Table  4.6.2.  The  addressing  mechanisms  of  the 
machine  crucially  depend  on  the  correctness  of  the  display  update 
procedure  addressing  environment  in  the  machine  to  be  correct  the 
transformation  performed  on  an  address  couple  by  the  NAME  instructions 
must  always  yield  the  right  index  into  ds .  Equivalently,  the  display 
must  always  contain  pointers  to  the  correct  scope  stack  entries.  The 
addressing  environment  changes  only  when  a  scope  is  exited  or  entered, 
and  by  design  this  display  update  procedure  is  always  invoked. at  these 
times.  The  procedure  starts  at  the  top  scope  stack  entry  and  traces 
down  the  static  link  chain  copying  the  static  link  entries  into  the 
appropriate  display  entries.  Thus  the  correctness  of  the  display_ 
update  procedure  depends  on  whether  the  static  link  chain  is  correct. 
The  rule  used  to  create  the  static  link  chain  is: 

a)  the  static  link  field  for  the  scope  stack  entry 
corresponding  to  the  outermost  block  (lexical 
level  zero)  is  irrelevant, 

b)  when  a  new  scope  with  lexical  level  greater  than 
zero  is  entered,  the  new  ss.l  field  is  set  to  point 
at  the  ss  entry  of  the  scope  which  statically 
contains  the  scope  being  entered. 
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The  only  difficulty  in  applying  this  rule  is  to  insure  that  the  ss 
entry  of  the  containing  scope  can  be  located  when  required.  Except 
for  procedures  passed  as  entry  parameters  the  correct  ss  entry  is 
always  known  from  the  point  of  scope  invocation.  In  the  case  of 
entry  parameters,  the  program  segment  descriptor  for  the  function 
or  procedure  is  never  moved  from  the  local  storage  of  the  scope 
which  statically  contains  it.  Instead  an  indirect  address  descriptor 
is  created  which  points  at  the  segment  descriptor.  When  the  parametric 
procedure  is  invoked  the  ss  index  portion  of  the  indirect  address 
descriptor  (Table  4.2.2)  is  used  to  set  the  static  link  field.  By 
definition  this  is  the  correct  entry  to  make  for  a  parametric 
procedure . 
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Instruction 

Definition 

ENTER 

argument  N  "number  of  parameters  being  passed" 
local  a,p 

a  -e  chain(dsp)  "address  of  segment  descriptor 

for  scope" 

p  scope  number  (a) 
if  N  ^  sct[p].p  then 

error  "incorrect  number  of  parameters" 
scope  enter (p,  a) 

SCOPE  ID 

argument  M  "scope's  index  in  scope  table" 

END 

argument  M  "scope's  index  in  scope  table" 
local  p,  q 

while  ss [ssp] .n  ^  M  do 

popss  "delete  contained  scopes" 

(p,  q)  -e  ds  [dsp]  "save  value  being  returned" 

dsp  ss  [ssp] .  d 

psp  ss  [ssp]  .p 

lr  ss  [ssp]  .w 

ds  [dsp]  (p,  q) 

popss 

display  update 

PARAM 

argument  N  "integer  identifying  parameter" 

local  a,  p 

a  •*-  chain(dsp-l)  "address  of  scope's  segment 

descriptor" 

p  -e  scope  number  (a) 

if  parmckl(dsp,  syt[sct [p]  .s+N-1])  then 

a  chain(dsp)  "call  parameterless  function" 
p  ■*-  scope  number  (a) 
scope  enter(p,  a) 

LFUNC 

argument  N  "number  of  parameters" 

local  p,  q 

(p,  q)  convert(ds  [dsp]  j  char) 

popds 

a  ■<-  chain  (dsp) 

left  side(ds[a],  N,  (p,  q) 

Table  4.6.1 

Block/Procedure  Instructions 
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Procedure 


Definition 


popss 


pushss 


display_update 


s c op e_n  umber 


scope_enter 


parmckl 


Table  4.6. 


ssp  •*-  ssp  -  1 
if  ssp  <  0  then 

error  "scope  stack  underflow" 

ssp  <•  ssp  +  1 

if  ssp  >  ss_size  then 

error  "scope  stack  overflow" 

local  q,  i 
i  ssp 
q  +-  1 

while  q  /  0  do  "stop  at  lexical  level  zero" 
q  set  [ss  [i]  .n] .  1 
display[q]  i 

i  s s  [i ] .  1  "on  to  next  link" 

parameter  A  "pointer  to  segment  descriptor  in  ds" 
local  i 

if  ds[A].t.p  i  1  then 

error  "not  a  procedure  segment" 
i  ds[A].v.b  "address  of  segment" 
if  ssm[i]  ^  SCOPEID  then 

error  "not  a  procedure  segment" 
scope_number  ssm[i  +  l] 

parameter  P  "index  of  scope's  entry  in  set" 
parameter  A  "pointer  to  scope's  segment  descriptor" 
pushss 

ss  [ssp]  (P,  ds[dsp].v.a,  sct[P].p,  psp,  lr) 
popds 

parmck2(sct[P]  .s ,  sct[P]  .p) 
ini t_s  cope (P) 
display_update 
pushps 

ps  [psp]  ■«-  (ds[A].a,  ds[A].b,  0,  dsp) 

parameter  P  "index  of  a  ds  entry  being  passed  as 

an  actual  parameter" 

parameter  S  "syt  entry  for  corresponding  formal 

parameter" 

"Checks  the  type  correspondence  between  actual 
and  formal  paramters .  May  use  convert  to  modify 
ds  [P] .  Returns  false  unless  actual  parameter 
is  a  parameterless  function  which  must  be  invoked 
to  obtain  a  scalar  value" 


2  Auxiliary  Procedures 
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Procedure 

parmck2 

left  side 


ini t  s cope 


Table  4.6 


Definition 

parameter  S  "index  of  1st  entry  for  scope  in  syt" 
parameter  N  "number  of  parameters  being  passed" 
"Performs  final  check  to  insure  that  each  actual 
parameter  is  of  the  correct  scalar  type.  May 
use  convert  to  modify  parameters  on  ds" 

parameter  I  "index  indicating  function  desired" 
parameter  N  "number  of  parameters" 
parameter  V  "value  from  right  side  of  assignment" 
"Performs  the  actions  required  to  implement  pseudo¬ 
functions  which  can  appear  on  the  left  side  of 
assignment  statements  (OUTPUT  and  SUBSTR)" 

parameter  P  "index  into  set" 

"Performs  the  actions  required  to  initialize 
local  storage  on  ds  for  the  scope  described  by 
sct[P].  For  variables  the  ds .  t  field  is 
initialized  from  syt.t.  For  constants  local 
to  the  scope  the  ds  entry  is  initialized  from 
syt.t  and  syt.v" 


2  Auxiliary  Procedures  (cont.) 
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4.7  Array  Storage  and  Utility  Instructions 

The  ALLOC  and  FREE  instructions  CTable  4.7.1)  implement  the 
array  storage  allocation  and  deallocation  required  for  the 
ALLOCATE  and  FREE  statements. 

Table  4.7.2  describes  several  miscellaneous  instructions 
required  to  complete  the  implementation  of  Student  PL.  The  BIT 
instruction  is  used  to  force  a  ds  entry  to  be  of  type  bit.  The 
HALT  instruction  signals  the  end  of  program  execution.  The  top 
two  entries  on  ds  are  interchanged  by  the  SWAP  instruction.  An 
entry  on  ds  with  undefined  type  (an  undefined  value)  is  created 
by  the  UNDEF  instruction. 

If  execution  error  messages  are  to  refer  to  lines  of  the 
original  source  program  (desirable  in  a  student  environment)  then 
a  mapping  from  instruction  address  to  corresponding  source 
program  line  number  must  be  available.  The  translator  from  Student 
PL  into  machine  language  emits  at  least  one  LINE  instruction  per 
Student  PL  statment.  This  instruction  merely  loads  an  integer 
(the  source  program  line  number)  into  the  line  register.  During 
execution  the  contents  of  the  line  register  always  indicates  the 
current  source  program  statement  being  executed. 

Auxiliary  functions  required  to  implement  the  ALLOC  and 
FREE  instructions  are  described  in  Table  4.7.3. 
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Instruction 


Semantics 


ALLOC 


FREE 


argument  N  "dimensionality  of  array" 
local  a,  q 

a  «-chain(dsp)  "address  of  array  variable" 
if  ds[a].t.a  =  0  then 

error  "attempt  to  allocate  non-array" 
q  +■  array_desc(N)  "get  space  for  descriptor" 
adt[q].n  N  "dimensionality" 

if  ds[a].t.u  =  0  then 

adt[a].l  ds[a].v.b  "prior  allocation" 
else 

ds  [a] .  t .u  0 
adt  [a] .  1  0 

make_array (q ,  N,  ds[a].t.s) 

ds[a].v.b  q  "point  to  new  descriptor" 

dsp  dsp  -  (N+N+l) 


local  a 

a  +■  chain(dsp)  "address  of  variable" 
if  ds[a].t.a  =  0  then 

error  "variable  is  not  an  array" 
if  adt [ds [a] .v.b] . 1  ^  0  then 

ds[a].v.b  adt  [ds  [a]  .  v.b] .  1  "prior  allocation 

else 

ds[a].t.u  •*-  1  "mark  as  undefined" 


Table  4.7.1  Storage  Management  Instructions 


Instruction 

Semantics 

BIT 

dsfdspj  convert  Cdsfdsp]  ,  bit) 

HALT 

"program  execution  terminates" 
executing  <-  0 

LINE 

argument  N  "source  program  line  number" 

lr  N  "set  line  register" 

SWAP 

local  p,  q 
(p,  q)  ds  [dspj 

ds  [dsp]  <-  ds[dsp-l] 
ds [dsp-1]  «-  (p,  q) 

UNDEF 

pushds 

ds  [dsp]  .  t.u  1 

Table  4.7.2  Utility  Instructions 
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Procedure 

Definition 

array  desc 

parameter  N  "dimensionality  of  array" 

"Obtains  space  in  adt  for  the  descriptor  of  an 

N  dimensional  array.  Returns  a  pointer  to 
the  space  obtained.  May  cause  compaction  of 
adt" 

make  array 

parameter  P  "index  to  array  descriptor  in  adt" 
parameter  N  "dimensionality  of  array" 
parameter  T  "scalar  type  of  the  array" 

"Obtains  storage  for  the  array  and  fills  in  the 

array  descriptor: 

1)  copies  upper- lower  bound  pairs  from  ds  into 
the  array  descriptor,  calculates  values 

for  the  multiplier  field  and  the  total  number 
of  array  elements. 

2)  obtains  space  for  the  array  elements  in  array 
storage.  May  cause  an  array  storage 
compaction. 

3)  fills  in  the  ds . t  field  for  each  array 

element,  ds.t.u  1  and  ds.t.s  T" 

Table  4.7.3 

Auxiliary  Procedures 
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CHAPTER  5 


Design  Improvement 


5.1  Introduction 

In  Chapter  2  we  described  a  computer  design  improvement  technique 
based  on  the  minimization  of  a  cost  measures.  In  this 
chapter  we  apply  the  technique  to  improving  the  design  of  the  initial 
Student  PL  machine  (hereafter:  the  machine) .  Recall  that  the 

cost  measure  defined  in  Section  2.4  contains  terms  relating 
to  the  size  of  programs,  the  number  of  memory  references  made 
during  program  execution,  and  the  quantity  of  information  extracted 
from  memory  during  program  execution.  We  will  therefore  focus  our 
attention  on  these  attributes  of  machine  performance.  Our  goal  is 

to  reduce  cost  by  improving  the  design  of  the  machine,  not 
by  making  the  machine  more  complex. 

To  study  the  behavior  of  the  machine  experimentally,  we  wrote 
a  translator  from  Student  PL  into  machine  language  and  an  interpreter 
for  the  machine.  To  obtain  a  representative  set  of  student  programs 
arrangements  were  made  to  use  the  Student  PL  trans lator/interpreter 
for  an  introductory  programming  course.  During  one  13-week  term 
approximately  50  students  used  Student  PL  to  solve  five  programming 
problems.  The  problems,  which  emphasized  non-numeric  computation, 
are  reproduced  in  Appendix  C. 
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Over  145,000  card  images  containing  1494  student  programs  and 
data  were  collected  for  later  analysis.  These  programs  exhibit 
several  kinds  of  bias.  Most  obviouslyj  they  are  unsophisticated  and 
small,  reflecting  both  the  problems  assigned  and  the  limited  expertise 
of  student  programers .  In  addition,  use  of  the  GO  TO  statement  was 
discouraged  by  the  instructor.  Strictly  speaking,  the  machine  design 
improvement  presented  here,  done  in  the  context  of  naive  student 
programmers,  should  be  repeated  if  the  machine  is  considered  for  other 
purposes.  On  the  other  hand,  we  do  not  expect  a  great  deal  of 
variation  in  the  results  obtained.  The  programming  language, 
problem  to  be  solved,  and  common  programming  habits  tend  to  smooth 
the  data. 

As  a  by-product  of  our  improvement  and  evaluation  of  the  Student 
PL  machine,  we  collected  a  considerable  amount  of  information  about 
the  characteristics  of  student  programs  and  about  the  characteristics 
of  the  machine.  The  part  of  this  information  which  is  useful  for 
design  improvement  and  evaluation  is  presented  in  Chapters  5  and  6. 

The  remainder  of  the  information,  which  may  be  useful  to  others 
interested  in  machine  design  is  tabulated  in  Appendix  D. 
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5.2  The  Economics  of  Change 

We  have  described  a  design  improvement  technique  which  can  be  used 
to  suggest  a  very  large  number  of  changes  in  the  design  of  a  computer. 
If  changing  the  design  of  a  computer  could  be  done  at  zero  cost 
then  it  might  be  feasible  to  make  all  the  changes  our  technique 
suggests.  However  in  practical  situations  changes  are  not  free; 
therefore  we  need  to  investigate  the  economics  of  making  design 
changes  in  order  to  formulate  a  policy  for  deciding  if  particular 
change  is  worth  making.  One  changes  the  design  of  a  machine  in  order 
to  reduce  the  long-term  operating  cost  of  using  the  machine.  Making 
a  change  incurs  capital  costs  arising  from  the  effort  required  to 
specify,  implement  and  document  the  change.  A  necessary  condition 
for  making  a  change  is  that  over  the  expected  life  of  the  machine  the 
savings  in  operating  costs  are  greater  than  the  capital  cost  of  making 
the  change. 

It  is  the  case  for  many  contemporary  computers  that  the  cost  of 
the  central  processing  unit  and  main  memory  is  becoming  an  increasingly 
small  percentage  of  the  total  computer  cost.  In  such  a  situation,  a 
more  practical  criterion  for  making  changes  is  that  the  changes  result 
in  a  substantual  long  term  savings  (e.g.,  a  change  which  saves  $1 
over  the  life  of  a  machine  is  not  a  significant  change). 

Evaluating  the  long-term  savings  resulting  from  a  change  is  not 
always  a  simple  matter.  From  the  machine  user's  point  of  view  some 
changes  are  transparent  (i.e.,  the  same  program  will  produce  the  same 
results)  and  some  are  not.  Transparent  changes  can  be  evaluated  on 
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the  basis  of  changes  in  the  value  of  the  cost  measure 
alone.  However  if  a  change  is  not  transparent  (e.g.,  programming 
becomes  easier  or  more  difficult)  then  the  effect  on  the  programmer 
must  also  be  evaluated.  There  will  be  a  (positive  or  negative)  cost 
associated  with  a  change  in  the  programmer's  environment  which  must 
be  included  when  computing  the  long-term  cost  change  to  determine 
if  a  change  is  worth  making. 

For  the  purposes  of  this  case  study  we  adopted  the  simpler  policy 
that  a  design  change  was  worth  making  only  if  it  resulted  in  at 
least  a  1%  improvement  in  one  of  the  terms  of  the  cost  measure. 
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5.3  Characteristics  of  Student  Programs 


We  begin  by  describing  some  general  characteristics  of  the  student 
programs  we  collected.  Of  the  1494  programs,  535  (35.5%)  contained 
one  or  more  syntax  errors  (for  a  detailed  discussion  of  these  errors 
see  [James  1971]).  These  syntactically  incorrect  programs  posed 
a  problem.  Our  intent  is  to  design  a  computer  to  execute  programs 
in  the  language  Student  PL  as  defined  in  Appendix  A.  If  we  include 
in  our  study  information  about  programs  which  are  not  legal  Student 
PL  then  we  are  effectively  designing  a  computer  to  execute  a  larger 
(almost  certainly  ambiguous)  language  which  contains  Student  PL.  In 
the  system  we  are  studying,  the  compiler  from  Student  PL  into 
Student  PL  machine  language  is  a  filter  which  traps  programs  that 
are  syntactically  incorrect.  We  therefore  need  consider  only  those 
programs  which  are  syntactically  correct  Student  PL.  Note  that 
while  we  are  not  evaluating  the  Student  PL  compiler  in  our  study, 
the  code  generation  algorithms  used  in  the  compiler  do  have  an 
influence  on  our  results.  As  is  evident  from  the  examples  in 
Appendix  B,  the  Student  PL  machine  was  designed  to  make  the  task  of 
compiling  Student  PL  as  straightforward  as  possible.  Thus  any  im¬ 
provements  in  execution  efficiency  we  observe  should  be  attributed 
to  a  better  machine  design  and  not  to  a  clever  compiler. 

Table  5.3.1  summarizes  the  syntactic  structure  of  the  programs. 
Preceeding  each  rule  of  the  grammar  for  Student  PL  is: 

1)  an  index  used  to  identify  the  rule  in  the  grammar, 

2)  a  count  of  the  number  of  times  the  rule  was  applied  during 
parsing  of  the  programs, 

3)  the  percentage  distribution  of  rules  applied, 

4)  the  percentage  distribution  of  alternatives  for  each  non¬ 
terminal  symbol. 
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Further  information  about  the  programs  can  be  derived  from  this 
table  (c.f.  [Knuth  1971]).  For  example: 


average  rules  applied 

E  count. 

l  = 

1568954 

program 

county 

959 

1636 


average  statements 


program 


average  catenate  operators  count  17705 

- -  =  - —  =  -  =  18.5 

program  county  959 

average  arithmetic  operators 
arithmetic  expression 

countn1_  count.  ir  +  count...  +  count.. „  +  count 

113+  115  116  11/ 


county  +  county 


count. 


41751 


43.6 


959 


count  n2 


count 


124 


12645 
=  109948 


1.15 


In  the  following  sections  we  analyze  information  gathered  about 
the  characteristics  of  programs  to  suggest  changes  in  the  design  of 
the  Student  PL  machine. 
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5.4  Instruction  Distributions 

Three  terms  in  the  cost  measure  we  are  using  to  improve 
the  machine  are  concerned  with  machine  instructions.  The  value 
of  the  measure  increases  with  the  number  of  bits  required  to  represent 
programs  and  with  the  number  of  instructions  executed;  by  reducing 
these  quantities  we  can  reduce  the  value  of  the  cost  measure. 

We  began  studying  how  instructions  were  used  in  the  machine  by 
tabulation  the  distribution  of  compiled  and  executed  instructions 
(Table  5.4.1)? 

Examining  the  instructions  which  occur  with  high  frequency  it 
is  apparent  that  the  LINE  instruction  (used  to  record  source  program 
line  numbers)  contributes  substantually  to  the  value  of  the  cost 
measure.  Several  alternatives  suggest  themselves: 

1)  eliminate  the  LINE  instruction  entirely  and  provide 
execution  error  messages  which  do  not  refer  to  the 
source  program, 

tune  the  Student  PL  translator  to  reduce  the  number 
of  LINE  instructions  emitted  (minimum  one  per  statement) , 

3)  replace  the  instruction  with  a  table  that  contains  the 
mapping  between  instruction  address  and  source  program 
line  number.  The  table  could  be  kept  on  secondary 
storage  except  when  needed  for  execution  error  messages. 

The  decision  to  make  change  1)  cannot  be  made  on  engineering  grounds 

alone  since  it  impacts  users  of  the  machine.  If  it  were  adopted,  the 

user  would  receive  less  precise  error  messages  and  would  presumably 

have  to  spend  more  time  debugging  programs.  The  second  and  third 


1. Since  the  Short  Name  and  Long  Name  Instructions  have  exactly  the  same 
set  of  predecessors  and  successors  they  have  been  represented  in  Tables 
5.4.1,  5.4.2  and  D.2  by  the  generic  NAME  instruction. 
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Table  5.4.1  Instruction  Distributions 


alternatives  can  be  made  transparent  to  the  user.  If  alternative  1) 
or  3)  were  adopted: 

1)  the  number  of  bits  required  to  store  programs  would 
be  reduced  by  14%, 

2)  the  number  of  memory  references  required  to  fetch 
instructions  would  be  reduced  by  8.7%, 

3)  the  number  of  bits  of  instruction  fetched  during 
program  execution  would  be  reduced  by  12.2%. 

From  our  data  we  estimate  that  alternative  2)  would  reduce  the  number 

of  line  instructions  compiled  and  executed  by  about  20%. 

To  make  a  decision  about  the  first  alternative  we  must  weigh  the 
potential  reduction  in  the  value  of  the  cost  measure  against 
to  cost  of  descreased  programmer  efficiency.  The  programmer  cost  has 
two  components:  increased  debugging  time  and  increased  classroom  time 
required  to  reach  a  given  level  of  programming  proficiency.  One 
cannot  be  certain  if  the  second  component  will  be  positive  or  negative. 
One  might  expect  precise  error  messages  would  allow  students  to  learn 
without  wasting  large  amounts  of  time  tracking  down  obscure  program 
errors.  Conversely,  if  program  debugging  is  a  painful  process,  the 
student  might  spend  more  care  and  thought  in  careful  program  preparation 
and  thus  develop  good  programming  habits  more  quickly.  We  will  not 
explore  this  interesting  question  further  here,  but  will  instead  make 
a  decision  on  subjective  grounds.  Error  messages  keyed  to  the  source 
program  have  proven  valuable  in  many  student-oriented  systems 
[Bauer  et^.£l_.  1968;  Cress  et_.al_.  1970]  so,  lacking  solid  justification 
for  deleting  line  numbers  from  execution  error  messages,  we  elect  to 
retain  them.  The  remaining  choice  is  between  the  second  and  third 
alternatives.  The  latter  is  obviously  superior  in  terms  of  reducing 
the  value  of  the  cost  measure. 
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A  question  which  immediately  arises  is  how  much  secondary  storage 
will  be  required  for  the  line  number  table.  The  translation  of  a 
source  program  results  in  a  number  of  program  segments  packed  into 
segment  memory.  Consider  a  data  structure  which  is  identical  to  the 
segment  structure  of  the  program  in  segment  memory  but  which  contains 
line  numbers  instead  of  instruction  codes.  If  an  error  occurs  while 
executing  an  instruction  at  some  location  in  segment  memory,  the  source 
program  line  number  associated  with  the  instruction  will  be  found  at 
the  corresponding  location  in  the  line  table.  This  line  number  table 
is  the  same  size  as  the  translated  program,  and  gives  an  upper  bound  on 
the  size  of  such  a  table. 
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To  continue  our  investigation  of  machine  instruction  usage  we 
tabulated  the  distributions  of  compiled  instruction  pairs  (Table  5.4.2) 
and  compiled  instruction  triples  (Table  D.2)  for  the  initial  machine 
without  the  LINE  instruction.  Blank  entries  in  some  columns  of  these 
tables  indicate  pairs  or  triples  which  occur  at  the  beginning  or  end 
of  program  segments. 

The  information  in  Tables  5.4. 1-2  will  be  used  for  less  trivial 
improvements  in  the  design  of  the  machine.  Pairs  or  triples  occurring 
with  high  frequency  suggest  new  Instructions.  Just  as  we  could  infer 
information  about  the  static  characteristics  of  programs  from 
Table  5.3.1,  we  can  infer  average  dynamic  program  characteristics  from 
Tables  5.4. 1-2  and  the  information  in  Appendix  B.  For  example: 
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program 
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average  number  of  traversals 
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Instruction 

Pair 

Count 

Percentage 

NAME 

EVAL 

113436 
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NAME 

NAME 

50  780 
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EVAL 

NAME 

37322 

6.5 

PARAM 

SWAP 
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2.4 

EVAL 

CAT 

13531 

2.4 

SUBS 

EVAL 

12143 

2.1 

EVAL 

SUBS 

11817 

2.1 

CAT 

NAME 

11584 

2.0 

EVAL 

PARAM 

10941 

1.9 

SWAP 

ENTER 

9809 

1.7 

LFUNC 

POP 

8678 
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Table  5.4.2  Distribution  of  Compiled  Instruction  Pairs 
(with  LINE  instruction  supressed) 
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5.5  Addressing  and  Data  Access 

An  overly  general  addressing  mechanism  was  provided  in  the 
initial  machine.  The  SHORT  NAME  instruction  (lexical  level  0-3, 
order  number  0-15)  and  the  LONG  NAME  instruction  (lexical  level 
0-7,  order  number  0-1023)  created  on  the  top  of  ds  indirect  address 
descriptors  pointing  at  values  in  ds .  The  EVAL  instruction  was  used 
to  fetch  values  to  the  top  of  ds .  Any  changes  we  can  make  to 
decrease  the  size  of  these  instructions  or  the  number  of  times  they 
are  executed  will  reduce  the  value  of  the  cost  measure.  From 
Tables  5.4. 1-2  we  see  that  over  90%  of  all  EVAL  instructions 
were  immediately  preceeded  by  a  NAME  instruction.  Our  figures 
indicate  that  combining  the  semantics  of  the  NAME-EVAL  pair  into 
a  single  LOAD  instruction  will  save  22.8%  on  the  number  of  instruction 
syllables  required  to  represent  the  programs,  as  well  as  reducing 
the  number  of  memory  references  required  to  access  instructions 
and  the  number  of  bits  of  instruction  fetched  from  memory. 

In  Figure  5.5.1  we  show  the  distribution  of  order  numbers  in 
compiled  NAME  instructions  as  a  function  of  lexical  level.  The 
dashed  line  indicates  the  boundary  between  addresses  representable 
in  the  short  (72.7%)  and  long  (27.3%)  forms.  If  we  could  find  a 
way  to  represent  more  addresses  in  the  short  form  then  the  value  of 
the  cost  measure  would  be  reduced.  Table  5.5.1  summarizes 
the  distribution  of  order  numbers  as  a  function  of  lexical  level 
and  also  shows  the  frequency  with  which  an  address  referred  to  the 
lexical  level  of  the  currently  active  scope.  Several  facts  are  evident: 
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Figure  5.5.1  Distribution  of  Order  Numbers  as  a  Function  of  Lexical  Level 


Lexical 

Level 

Frequency 

Percentage 
of  total 

Number  at 
current  level 

Percentage  at 
current  level 

Compiled 
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11.7 

959 

4.5 
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150018 

81.5 

138424 

92.6 
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6.5 

11826 

99.6 
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481 

0.3 

481 
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Total 
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Executed 

0 

164308 

3.4 

959 

0.6 

1 

4025347 

83.7 

3254709 

80. 7 

2 

602435 

12.5 

578108 

95.9 

3 

19243 

0.4 

19243 

100.0 

Total 

4811333 

3853019 

Table  5.5.1 

Distribution  of  Compiled 
References  as  a  Function 

and  Executed  Address 
of  Lexical  Level  and 

Current  Lexical  Level 
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1)  Over  80%  of  all  addresses  refer  to  the  main  program 
(lexical  level  1) 

2)  Except  for  lexical  level  0  (built-in  functions) , 
over  80%  of  all  address  references  to  a  given 

level  came  from  the  same  level.  (  the  "current"  level) 

To  take  advantage  of  these  patterns  of  address  reference,  we  propose 
a  change  in  the  encoding  of  lexical  level  -  order  number  in  the 
name  instructions.  The  ability  to  partition  instruction  syllables 
as  described  in  Figure  5.5.2  will  be  required  to  implement  our 
changes.  The  new  instructions  we  propose  are  described  in  Table 
5.5.2.  The  short  forms  require  only  one  instruction  syllable. 

If  they  are  executed  at  the  main  program  level,  then  the  op.v 
field  is  used  as  an  order  number  (range  0-63) .  If  they  are 
executed  at  any  other  level,  the  op. a  field  is  used  to  select 
between  the  current  level  and  the  main  program  and  the  op.b  field 
is  used  as  an  order  number  (range  0-31) .  The  long  forms  of  the 
instructions  allow  lexical  levels  0-7  to  be  addressed  with  order 
numbers  0  to  255. 

We  estimate  that  these  changes  will  result  in: 

1)  a  23%  reduction  in  the  number  of  instruction 
syllables  required  to  represent  the  set  of 
sample  programs, 

2)  a  17%  reduction  in  the  number  of  memory 
references  required  to  access  instructions, 

3)  a  13.5%  reduction  in  the  number  of  bits  of 
instruction  fetched  during  program  execution. 

To  measure  how  close  our  encbding  of  addresses  came  to  the  best 

possible  encoding,  we  calculated  the  minumum  redundancy  encoding 

[Huffman  1952]  of  the  address  couples  that  occurred  in  the 
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Instruction  Syllable  -  op 


op 

op.p 

op  .V 

op .  a  |  ©p .  b 

op .  c  op .  1 

Sub  fie  Ids : 

op.p 

Instruction  prefix,  2  bits  used  to 
distinguish  classes  of  instructions 

op .  V 

Value  field,  6  bits  treated  as  a 
positive  integer  0-63 

op .  a 

One  bit  flag  field 

op  .b 

Short  value  field,  5  bits  treated  as 
a  positive  integer  0-31 

op.  1 

Level  field,  3  bits  treated  as  a 
positive  integer  0-7 

op .  c 

Subfield  to  select  an  instruction 
within  the  instruction  ciass 
specified  by  op.p 

Figure  5.5.2  Partitionings  of  the  Instruction  Syllable 
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SHORT  NAME 


local  p,q,a 


"op.p  =  00" 


if  current  level  =  1  then 


p  f-  1 

q  +-  op.v 


"lexical  level  one" 
"order  number" 


else  if  op. a  =  1  then 

p  +-  1 

q  +-  op.b 


"lexical  level  one 
"order  number" 


else 


SHORT  LOAD 


LONG  NAME 


LONG  LOAD 


p  +-  current  level  "current  lexical  level 


q  +-  op.b 


"order  number" 


pushds 

a  +-  ss [display [p] ]. d  +  q 

if  ds[a].t.s  =  ind  then  "indirect  chain" 
ds  [dspj  +-  ds  [a] 
else 

ds  [dsp]  .  t  •*-  (0,  0,  0,  ind) 
ds[dsp].v  +-  (  display  [p],  q) 

local  p,q  "op.p  =  01" 

if  current_level  =  1  then 

p  +-  1  "current  level  =  one" 

q  +-  op.v  "order  number" 

else  if  op. a  =  1  then 

p  +-  1  "level  one" 

q  +-  op.b  "order  number" 

else 

p  +-  current_level  "current  lexical  level 
q  +-  op.b 
pushds 

ds  [dsp]  +-  ds  [chain(ss  [display  [p]  ].  d  +  q)  ] 
if  ds[dsp].t.u  =  1  then 

error  "fetched  undefined  value" 

argument  N 
local  p,a 
pushds 

a  +-  ss  [display[op.  1]]  .d+N  "ds  address" 
if  ds[a].t.s  =  ind  then  "indirect  chain 

ds[dsp]  +-  ds[a] 
else 

ds[dsp].t  +-  (0,  0,  0,  ind) 
ds[dsp].v+-  (display  [op.  1] ,  N) 

argument  N 
pushds 

ds  [dsp]  +-  ds  [chain(ss  [display  [op.  1]  ]  .d+N)  ] 
if  ds[dsp].t.u  =  1  then 

error  "fetched  undefined  value" 


SHORT  LOAD 


LONG  NAME 


LONG  LOAD 


Table  New  Data  Reference  Instructions 


Student  PL  object  programs.  Using  a  minimum  redundancy  encoding 
714494  bits  were  required  to  represent  the  address  couples 
(average  5.53  bits  per  address).  For  the  same  set  of  addresses 
our  encoding  required  827877  bits  (average  6.42  bits  per  address). 
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5.6  Constants 


Constants  appearing  explicitly  or  implicitly  in  source  programs 
contribute  to  the  value  of  the  cost  measure  in  several  ways: 

1)  since  each  constant  resides  on  ds  (see  Section 
4.2)  an  address  couple  is  required  to  reference  the 
constant.  The  occurrence  of  many  constants  in 

a  program  will  mean  that  the  long  forms  of  NAME 

and  LOAD  instructions  will  have  to  be  used  to  access 

variables  and  constants,  thus  increasing  program  size. 

2)  an  entry  in  ds  will  be  required  to  hold  the 
type  and  value  of  the  constant  thus  increasing 
the  space  required  to  store  program  data, 

3)  each  time  a  constant  is  used  during  program 
execution  its  value  must  be  fetched  to  the  top 
of  ds  thus  increasing  the  number  of  memory 
references  required  to  access  data. 

To  see  if  there  was  a  pattern  in  the  way  that  constants  were  being 

used  which  could  be  exploited  to  improve  the  design  of  the  machine^ 

we  tabulated  the  distribution  of  constants  appearing  in  programs  by 

type  of  constant  (Table  5.6.1).  For  each  type  of  constant  the 

range  of  values  encountered  was  also  tabulated  (Table  5.6.2  and  D.5) 

Several  facts  are  apparent  from  the  distribution  in  these  tables: 

1)  over  72%  of  all  constants  were  of  type  FIXED, 

2)  nearly  half  of  all  constants  of  type  FIXED  had 
the  value  one;  presumably  programmers  used  the 
constant  one  frequently  because  it  is  the  default 
value  for  array  origins,  character  string  origins, 
etc.  , 

3)  using  normal  binary  positional  notation  almost 
all  constants  of  type  FIXED  could  be  represented 
using  only  a  few  bits. 
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Constant 

Count 

Percentage 

Type 

FIXED 

43729 

72.8 

CHARACTER 

15265 

25.4 

FLOAT 

1014 

1.7 

BIT 

49 

.  1 

Table  5.6. 

1  Distribution  of  Constants  by  Typ 

e 

Range 

of 

Count 

Percentage 

Cumulative 

Value 

Percentage 

[  o  , 

2°  ) 

5478 

12.5 

12.5 

[  2°  , 

2 1  ) 

20991 

48.0 

60.5 

[  21  , 

22  ) 

3316 

7.6 

68.1 

[  22  , 

2 3  ) 

4149 

9.5 

77.6 

[  23  , 

24  ) 

6822 

15.6 

93.2 

[  24  , 

25) 

1490 

3.4 

96.6 

[  25  , 

2 6  ) 

986 

2.2 

98.8 

[  26  , 

2 7  ) 

306 

0.7 

99.5 

[  2 7  , 

2  8  ) 

27 

0.1 

99.6 

[  2 8  , 

29  ) 

2 

0.0 

99.6 

[  29  , 

2 10) 

121 

0.3 

99.9 

[  213, 

214) 

24 

0.1 

100.0 

[  2 30 , 

231) 

15 

0.0 

100.0 

Table  5.6 

.2  Distribution  of  FIXED  Constant 

Values 

LITERAL 

pushds 

ds [dsp] 

.  t  (0 ,  0 ,  0 ,  fixed) 

ds [dsp] 

.v  +■  op.v 

Table  5.6 

.3  The 

LITERAL  Instruction 
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The  LITERAL  instruction  (Table  5.6.3)  was  designed  to  take  advantage 
of  the  observed  distribution  of  FIXED  constants.  The  6-bit  op.v  field  is 

I 

large  enough  to  hold  98.8%  of  all  FIXED  constants  appearing  in  the  set  of 
sample  programs  (72%  of  all  programmer  specified  constants).  The  LITERAL 
instruction  will  reduce  the  value  of  the  cost  measure  four  ways: 

1)  it  makes  more  address  couples  available  for 
addressing  variables,  thus  fewer  long  NAME/LOAD 
instructions  will  be  used  and  the  number  of  bits 
required  to  represent  programs  will  be  less, 

2)  long  LOAD  instructions  used  to  fetch  constants 
will  be  replaced  by  shorter  LITERAL  instructions 
thus  reducing  the  size  of  programs, 

3)  less  storage  will  be  required  for  program  data 
since  small  FIXED  constants  no  longer  reside  in  ds , 

4)  one  less  memory  reference  will  occur  each  time  a 
small  FIXED  constant  is  used  since  the  value  of 
the  constant  need  not  be  fetched  from  ds. 

We  cannot  make  a  more  quantitative  estimate  of  the  reduction  in  value 

of  the  cost  measure  resulting  from  adding  the  LITERAL  instruction 

to  the  machine,  since  the  information  we  gathered  does  not  distinguish 

between  accessing  variables  and  accessing  constants.  However,  qualitatively 

the  large  number  of  FIXED  constants  appearing  in  programs  (average  45.6 

FIXED  constants  per  program)  leads  us  to  believe  that  adding  the  LITERAL 

instruction  is  worthwhile. 

Note  that  there  is  an  interaction  between  the  effect  of  adding  the 
SHORT/LONG  NAME/LOAD  instructions  and  the  effect  of  adding  the  LITERAL 
instruction  which  replaces  some  LOADs.  Thus  the  reductions  in  the  value 
of  the  cost  measure  which  we  calculate  separately  for  each  design 
change  are  not  strictly  additive.  We  will  compute  the  actual  change  in 
the  cost  measure  in  Section  5.10. 
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5.7  Conditional  Statements 

In  the  initial  machine  implementation  of  conditional  statements 
(see  Table  B.3-4),  one  BIT  and  one  SUBS  instruction  were  executed  to 
select  between  program  segment  descriptors  for  the  two  alternative 
statements.  For  the  IF-THEN  conditional  statement  one  of  the  descriptors 
was  null.  The  high  execution  frequency  of  the  BIT  instruction  shows 
that  many  conditional  statements  were  executed  and  suggests  that  the 
implementation  of  conditional  statements  be  reviewed. 

In  retrospect  the  original  implementation  was  inefficient  for 
several  reasons : 

1)  using  the  SUBS  operator  resulted  in  many 
unnecessary  memory  references  since  SUBS 
does  more  checking  than  is  required  for 
conditional  statements, 

2)  programs  would  be  smaller  if  the  instruction 
sequence  BIT  SUBS  were  replaced  by  a  single 
instruction, 

3)  the  distribution  by  length  of  program  segment 
descriptors  fetched  to  ds  during  program 
execution  (Table  5.7.1)  shows  that  over  25% 
of  all  such  descriptors  were  null.  The  high 
frequency  of  null  segments  indicates  that  many 
unnecessary  memory  references  are  taking  place. 

The  last  point  is  particularly  important  since  placing  a  segment  into 

execution  involves  several  memory  references  to  ds  and  ps. 

We  propose  two  new  instructions  to  implement  conditional  statements 
(Table  5.7.2,  also  see  Table  B.3-4). From  our  data  we  estimate  that  these 
instructions  will: 
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1)  reduce  the  space  required  to  store  programs 
by  1.9%, 

2)  reduce  the  number  of  memory  references  required 
to  fetch  instructions  by  9.8%, 

3)  reduce  the  number  of  bits  of  instruction  accessed 
during  execution  by  8.6%. 
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Segment  Length 
in  Syllables 

Count 

[  o  .  2°  ) 

71754 

[  2°  ,  21  ) 

0 

[  21  ,  22  ) 

1733 

[  22  ,  23  ) 

11630 

[  23  ,  24  ) 

33543 

[  24  ,  2S  } 

70996 

[  25  ,  26  ) 

46226 

[  26  ,  27  ) 

26790 

[  27  ,  28  ) 

4902 

[  28  ,  29  ) 

349 

Percentage 

Cumulative 

Percentage 

26.8 

26.8 

.0 

26.8 

.7 

27.5 

4.3 

31.8 

12.5 

44.3 

26.5 

70.8 

17.3 

88.  1 

10.0 

98.  1 

1.8 

99.9 

.1 

100.0 

Table  5.7.1  Distribution  of  Length  Field  in  Program  Segment 

Descriptors  Fetched  to  Data  Stack  during  Execution 
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IF  1 


IF2 


Table  5 


local  p,q,a 

(p,  q)  convert  (ds  [dsp- 1]  ,  bit)  "force  bit  value" 
if  q  then 
pushps 

a  <-  chain(dsp) 

ps  [psp]  <-  (ds[a].v.a,  ds[a].v.b,  0,  dsp-2) 
popds 
popds 

local  p,q,a 

(p,  q)  convert(ds  [dsp-1] ,  bit) 

pushps 

if  q  then 

a  +-  chain (dsp)  +  1 

else 

a  +■  chain  (dsp) 

ps  [psp]  •<-  (ds[a].v.a,  ds[a].v.b,  0,  dsp-2) 

popds 

popds 


.7.2  Conditional  Statement  Instructions 
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5.8  Builtin  Functions 


In  the  initial  machine  the  same  procedure  calling  mechanism  was 
used  for  both  user-written  and  builtin  functions.  The  high  compilation 
and  execution  frequencies  of  the  instructions  used  to  call  procedures 
(ENTER,  PARAM,  SWAP)  raised  doubts  about  the  wisdom  of  this  choice. 
Further  investigation  showed: 

1)  76%  of  all  procedure  calls  were  to  builtin  functions 
(see  Table  6. 3. 1  for  a  detailed  distribution), 

2)  even  in  programs  containing  significant  usage  of 
user-written  procedures,  56%  of  all  procedure 
calls  were  still  to  builtin  functions. 

Using  a  distinct  calling  sequence  for  builtin  functions  will  save 
a  PARAM  and  a  SWAP  instruction  for  each  parameter  passed  to  the  function. 
Using  the  distribution  of  number  of  parameters  passed  to  procedures  in 
Table  5.8.1  and  assuming  that  76%  of  all  parameters  were  passed  to 
builtin  functions  we  can  estimate  the  potential  savings: 

1)  a  2.1%  reduction  in  the  space  required  to 
represent  programs, 

2)  a  1.2%  reduction  in  the  number  of  memory 
references  required  to  fetch  instructions, 

3)  a  1.9%  reduction  in  the  number  of  bits  of 
instruction  fetched  during  program  execution. 

The  BfUNC  instruction  (Table  5.8.2)  implements  a  simpler  mechanism 

for  calling  builtin  functions. 
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I 


Number  of  Frequency-  Percentage 

Parameters 


0 

1 

2 

3 

4 


4333 

30.6 

2393 

16.9 

1420 

10.0 

5960 

42.2 

36 

0.3 

Table  5.8.1  Distribution  of  Number  of  Parameters 
per  Procedure  call 


BFUNC  argument  I  "index  specifying  function" 

local  n 

n  ds[dsp].v  "actual  parameter  count"  ( 

ds  [dsp]  builtin_function(l  ,n)  "perform  function" 

Table  5.8.2  The  BFUNC  Instruction 
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5.9  Other  Changes 

In  this  section  we  describe  several  minor  changes  to  the  design  of 
the  machine  which  were  suggested  by  our  data. 

Seventy-two  percent  of  all  STORE  instructions  were  immediately 
followed  by  a  POP  instruction  to  clear  ds .  Combining  the  actions  of 
these  two  instructions,  the  STORED  instruction  will  save  an  estimated 
2.2%  of  the  space  required  to  store  programs  as  well  as  memory 
references  during  program  execution. 

The  DOTEST  instruction  is  always  followed  by  a  CRET  instruction 
and  a  DOINCR  is  always  followed  by  a  CYCLE  (Table  B.7).  By  adding 
the  action  of  the  second  instruction  in  each  pair  to  the  definition 
of  the  first  instruction  we  save  an  estimated  0.9%  in  the  space 
required  to  store  programs,  but  more  importantly,  we  save  two  instruction 
executions  and  their  associated  memory  references  for  each  traversal 
of  an  iterative  DO  group.  We  estimate  that  these  pairings  will 
reduce  the  number  of  instructions  executed  by  2.5%  with  a  corresponding 
reduction  in  the  number  of  memory  references  required. 

After  the  NAME-EVAL  pair,  the  next  most  frequent  occurrence  of  the 
EVAL  instruction  was  in  the  pair  SUBS-EVAL  (71%  of  all  SUBS  instructions). 
We  estimate  that  the  combined  instruction  SUBSEVAL  will  reduce  the 
space  required  for  program  storage  by  1.4%  and  reduce  the  number  of 
instructions  executed  by  4.4%. 

Table  5.9.1  defines  the  new  instructions  described  in  this  section. 
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STORED 


SUBSEVAL 


DOTEST 


DOINCR 


Table 


local  a 

a  chain(dsp-l) 

if  ds[a].t.a  =  1  then  "array  on  left" 

if  ds[dsp].t.a  =  0  then  "scalar  on  right" 

array_fill (ds [a] ,  convert (ds [dsp] ,  ds[a].t.s) 
else  "array  on  right" 

array_copy (ds [a] ,  ds [dsp] ) 

else 

ds  [a] .  t  .u  0 

ds[a].v-*-  convert (ds [dsp] ,  ds[a].t.s) 
popds 
popds 

argument  N  "subscript  count" 
local  a,  p,  q 

a  chain(dsp-N)  "locate  variable" 
if  ds[a].t.a  ^  1  then 

error  "attempt  to  subscript  non  array" 

(p,q)  subscript  (ds[a].v.b,  N) 
dsp  <-  dsp  -  N 
ds  [dsp]  ds[adt[p].b  +  q] 
if  ds[dsp].t.u  =  1  then 

error  "use  of  undefined  value" 

local  a,p 

a  chain  (dsp  -  2)  "address  of  loop  variable" 
ds[dsp-l]  convert  (ds  [dsp- 1] ,  ds[a].t.s) 
if  ds[dsp].v  <  0  then  "test  sign  of  increment" 

p  +■  ds  [a]  ‘t,S  ds[dsp-l].v 

else 

p  ds  [a] .  v9^^  ’  t‘ S  ds[dsp-l].v 

if  p  =  false  then 
popiis 

local  a 

a  chain(dsp-2) 

ds  [dsp]  -e  convert  (ds  [dsp]  ,  ds[a].t.s) 
ds[a].v  ds  [a] .  v9^^a^ ' t,S  ds[dsp].v 
ps  [psp]  .  r  0 

5.9.1  New  instructions 
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5.10  Closing  the  Loop 

In  the  preceeding  sections  we  suggested  a  number  of  changes 
to  the  design  of  the  Student  PL  machine.  Each  change  was 
justified  by  an  anticipated  reduction  in  some  terms  of  the 
cost  measure.  As  we  discussed  in  Section  5.6,  interactions 
between  the  changes  prevent  us  from  simply  summing  the  in¬ 
dividual  reductions  to  obtain  the  total  reduction  in  each 
term.  In  addition,  it  was  not  always  possible  from  our  data 
to  quantitatively  estimate  the  effect  of  each  design  change  on 
each  term  of  the  measure,  so  our  estimates  could  be  low.  To 
validate  our  design  technique  and  to  verify  that  the  proposed 
changes  did  actually  result  in  an  improved  machine  design,  the 
changes  were  implemented  in  the  Student  PL  compiler/ interpreter 
and  the  complete  set  of  student  programs  was  rerun.  By  computing 
each  term  in  the  cost  measure  we  were  able  to  determine  the  exact 
reduction  in  each  term.  Our  results  are  summarized  below: 


Term 

Average 

Reduction 

Predicted 

Reduction 

instruction  bits 

51.1% 

45.5% 

data  bits 

-6.9% 

- 

instruction  memory 

36.9% 

25.9% 

accesses 

data  memory  accesses 

49.9% 

- 

instruction  bits 

58.1% 

- 

accesses 

data  bits  accessed 

62.3% 

_ 

In  the  remainder  of  this  section  we  will  discuss  some  of  the 
reasons  for  this  substantial  reduction  in  the  cost  of  executing 
programs . 
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The  distribution  of  compiled  and  executed  instructions  for  this 
new  run  (Table  5.10.1)  illustrates  several  effects  of  the  changes  (c.f. 
Table  5.4.1): 

1)  six  of  the  ten  most  frequent  instructions  are  new, 

2)  virtually  all  instances  of  the  EVAL  instruction  have 
been  replaced  by  a  LOAD  or  SUBSEVAL, 

3)  the  LITERAL  instruction  has  replaced  many  NAME-EVAL  pairs, 

4)  the  number  of  instructions  used  to  call  procedures 
(SWAP,  PARAM,  ENTER)  has  decreased  markedly,  a  result 
of  adding  the  BFUNC  instruction. 

Tables  D.3  and  D.4  give  the  distribution  of  compiled  instruction 
pairs  and  triples  for  the  new  machine  (c.f.  Table  5.4.2  and  Table  D.2). 

To  determine  the  effect  of  adding  the  LITERAL  instruction  on  the 
number  of  items  stored  on  ds  and  on  the  number  of  address  couples 
required,  we  plotted  the  relative  percentage  distribution  of  address 
couples  appearing  in  compiled  NAME  and  LOAD  instructions  (Figure  5.10.1). 
Comparing  the  data  in  this  figure  with  that  in  Figure  5.5.1  we  observe 
that  the  number  of  order  numbers  required  at  lexical  level  one  has  been 
reduced  by  24%.  From  Table  5.10.1  we  can  see  that  91.6%  of  all  addresses 
were  represented  in  the  short  forms  of  the  NAME/LOAD  instructions. 

To  examine  the  changes  in  each  term  of  the  cost  measure  in  more 
detail  we  plot  separately  the  ratio  of  values  for  each  term.  We  will 
display  these  ratios  as  a  function  of  the  value  of  the  measure  for  the 
initial  machine.  This  particular  form  of  presentation  indicates  if  the 
factor  by  which  our  technique  improves  the  design  of  the  machine  varies 
as  a  function  of  program  size.  To  reduce  the  number  of  data  points 
plotted  and  to  smooth  the  data,  we  plot  the  average  value  of  the  ratio 
corresponding  to  each  value  of  the  measure  for  the  old  machine. 

Figure  5.10.2  describes  the  change  in  the  program  code  size  term 
of  the  measure  as  a  result  of  the  design  changes.  We  observe: 
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Table  5 . 10 J 1  Distribution  of  Compiled  and  Executed  Instructions 
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Percentage  of  all 
Order  Numbers 
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Figure  5.10.1  New  Machine  -  Distribution  of  Order  Numbers  as  a  Function  of  Lexical  Level  in  the  Address  Couple 
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1)  the  average  reduction  in  code  size  (space 
required  to  store  programs)  was  51.1%, 

2)  the  percentage  reduction  increases  with  the 
size  of  program. 

Figure  5.10.3  gives  the  ratios  of  data  area  sizes  for  the  old  and 
new  machines.  The  6.9%  growth  in  the  size  of  the  data  area  (scope 
table  plus  run  symbol  table  plus  line  number  table)  is  due  to  the 
line  number  table.  In  computing  data  area  size  we  used  the  upper 
bound  for  the  size  of  the  line  number  table  described  in  Section  5.4. 
Figure  5.10.4  shows  that  on  average  our  changes  resulted  in  a  9.3% 
reduction  in  the  total  size  of  programs.  As  we  mentioned  in  Section 
5.4,  the  line  number  table  could  reside  on  secondary  storage  since 
it  is  only  required  when  an  error  occurs  during  program  execution. 
Figure  5.10.5  shows  the  ratio  of  total  program  sizes  excluding  the 
space  required  for  the  line  number  table.  The  reduction  in  total 
program  size  exhibited  in  this  figure  results  from  the  decrease  in 
program  code  size  and  also  from  the  reduction  in  data  area  size 
caused  by  adding  the  LITERAL  instruction.  The  average  size  reduction 
in  Figure  5.10.5  is  22.5% 

The  remaining  terms  in  the  cost  measure  are  directly 
or  indirectly  related  to  the  number  of  instructions  executed.  To - 
evaluate  changes  in  these  terms  of  the  measure  we  first  excluded  from 
our  set  of  sample  programs  all  those  programs  which  terminated 
execution  because  they  exceeded  the  fixed  time  limit  imposed  on 
student  program  execution.  Usually  these  programs  contained  infinite 
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Figure  5.10.5  Ratio  of  Total  Program  Size  (exclusive  of  line  number  table) 
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loops,  and  therefore  the  number  of  instructions  executed  was  determined 
primarily  by  the  speed  of  the  host  computer  used  to  execute  the 
Student  PL  interpreter.  Programs  which  terminated  execution  in  some 
other  way  (746  out  of  959  programs)  were  assumed  to  have  reached  the 
same  final  state  on  the  new  and  old  machined 

Figure  5.10.6  show  the  ratios  of  number  of  instructions  executed 
on  the  two  machines  to  execute  the  same  set  of  programs.  The  average 
reduction  in  number  of  instructions  executed  is  46%. 

Figure  5.10.7  which  shows  the  number  of  memory  references  required 
to  fetch  instructions  show  a  similar  gain.  The  average  reduction  in 
number  of  memory  references  was  36.9% 

The  ratios  of  memory  references  required  to  fetch  data  (Figure  5.10.8) 
indicates  a  considerable  variability  in  the  percentage  reduction 
achieved.  This  statistic  is  very  sensitive  to  the  relative  frequency 
of  references  to  integer  constants  (implemented  using  the  LITERAL 
instruction  in  the  new  machine)  and  references  to  other  kinds  of 
constants  and  to  variables.  The  average  reduction  in  number  of  data 
memory  references  is  49.9%. 

Figure  5.10.9  show  the  ratios  of  number  of  bits  of  instructions 
fetched  during  program  execution  on  the  two  machines.  This  graph 
again  reflects  the  almost  50%  reduction  in  the  number  of  instructions 
executed.  The  average  reduction  in  number  of  bits  of  program  fetched 
is  58.1%. 

1.  To  verify  this  assumption  we  tabulated  the  number  of  executions  of 
instructions  which  were  invariant  under  our  design  changes  (ADD, 

CAT,  LE,  LFUNC,  etc.).  The  sum  of  these  execution  counts  for  the 
two  machines  differed  by  less  than  1%. 
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Figure  5.10.6  Ratio  of  Instructions  Executed 
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Figure  5.10.7  Ratio  of  Program  Memory  References 
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Figure  5.10.9  Ratio  of  Bits  of  Program  Fetched 


The  corresponding  ratios  of  number  of  bits  of  data  fetched  during 
program  execution  are  given  in  Figure  5.10.10.  The  reductions 
achieved  result  primarily  from  the  LITERAL  instruction  and  the  simpler 
calling  sequence  for  builtin  functions.  The  average  reduction  is 
62.3%. 

The  statistics  presented  in  this  section  support  our  contention 
that  even  a  reasonably  optimized  intuitively-designed  language  directed 
machine  can  be  substantially  improved  by  the  experimental  design  process 
described  in  Chapter  Two. 
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CHAPTER  6 


Experimental  Computer  Evaluation 


6.1  Introduction 

In  Chapter  2  we  described  an  experimental  technique  for  comparing 
and  evaluating  the  performance  of  digital  computers.  In  this  chapter 
we  demonstrate  the  application  of  the  technique  with  a  comparison  of 
the  Student  PL  Machine  to  a  contemporary  general  purpose  computer. 

In  its  abstract  form  the  evaluation  technique  consists  of 
several  steps: 

1)  selecting  a  high-level  programming  language  and 
partitioning  it  into  a  set  of  language  fragments, 

2)  associating  with  each  language  fragment  attributes  of 
computer  performance  (relative  to  a  given 

cost  measure), 

3)  selecting  a  set  of  programs  to  represent  the 
anticipated  (or  actual)  workload  of  the  computers 
being  compared, 

4)  tabulating  the  static  and  dynamic  occurrences  of 
each  language  fragment  when  the  set  of  programs 
are  compiled  and  executed  on  each  computer, 

5)  using  the  tabulations  of  static  and  dynamic 
occurrences  to  compute  a  value  of  the  cost 
measure  for  each  computer  being  compared. 

To  apply  the  technique  to  a  particular  evaluation  problem,  the  computers 

to  be  evaluated,  the  cost  measure,  the  programming  language,  and 

the  set  of  programs  must  be  specified.  In  the  next  section  we  describe 

how  these  parameters  to  the  evaluation  process  were  selected  for  our 

case  study.  The  evaluation  experiment  itself  (steps  4  and  5  above)  is 

then  described  in  Section  6.3. 
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6.2  Experiment  Parameters 

The  choice  of  computers  to  be  evaluated  in  this  case  study  was 
made  for  very  pragmatic  reasons.  One  computer  was  obviously  the 
Student  PL  Machine.  The  other  computer  had  to  satisfy  two  practical 
criteria: 

1)  it  had  to  support  an  implementation  of  PL/I 
which  could  be  compared  with  Student  PL, 

2)  it  had  to  be  sufficiently  accessible  so  that 
we  could  economically  obtain  the  information 
required  to  associate  performance  attributes 
with  programming  language  fragments . 

The  only  programming  language/ computer  which  readily  met  these  criteria 

was  IBM's  implementation  of  PL/I (F)  on  the  IBM  System/ 360^  [IBM  1969a, 

1969b,  1969cJ.  We  therefore  choose  to  compare  the  Student  PL  Machine 

against  the  System/ 360. 

The  cost  measure  used  in  the  case  study  was  described 
in  Sections  2.3  and  2.4.  It  is  a  weighted  sum  of  two  terms 
describing  the  static  characteristics  of  programs: 

a  number  of  bits  required  to  represent  instructions, 

a0  number  of  bits  required  to  represent  data, 
and  four  terms  describing  the  dynamic  characteristics  of  programs: 

a^  the  number  of  memory  references  required  to 
fetch  instructions  during  program  execution, 

a^  the  number  of  memory  references  required  to 
access  (fetch  or  store)  data  during  program 
exe cution, 

a,,  the  number  of  bits  of  instruction  fetched  during 
program  execution, 

a^  the  number  of  bits  of  data  accessed  during  program 
execution. 


1.  Several  other  systems,  Cornell's  PL/C  and  the  Hultics  PL/I 
would  have  been  acceptable  if  they  had  been  readily  available 
to  the  author. 
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Assigning  values  to  the  weighting  factors  in  the  cost  measure 
posed  a  problem.  As  we  have  previously  stated,  we  wished  to  keep 


the  discussion  in  this  thesis  independent  of  the  cost  of  any 
particular  hardware  technology.  In  addition  it  would  be  difficult 
to  estimate  the  cost  of  the  Student  PL  Machine  without  at  least 
specifying  a  hardware  implementation  for  the  machine  in  considerable 
detail,  a  process  we  were  reluctant  to  undertake.  To  resolve  this 
difficulty  we  will,  as  in  the  previous  chapter  consider  only  the 
individual  terms  in  the  cost  measure  and  leave  the  values  of  the 
weighting  factors  uk^  unspecified.  Thus  we  will  only  calculate 
the  summations: 


m 

Z  • 

nCp) 

j  =  l 

Q  .  . 

m 

Z 

n(p) 

j  =  l 

qij 

I  Cp) 


i  =  1,2 


i  =  3, 4, 5, 6 


and  omit  the  weighted  summation  of  these  terms. 

The  programming  language  used  in  our  case  study  will  of 
course  be  Student  PL.  One  might  wonder  if  it  is  reasonable  to 
compare  an  implementation  of  Student  PL  with  an  implementation  of 
full  PL/I?  That  is,  whether  a  compiler  specifically  designed  to 
implement  Student  PL  on  the  System/360  would  use  substantially 
different  (and  less  expensive  in  terms  of  the  cost  measure)  instruction 
sequences  and  internal  data  representations  than  those  used  by 
the  PL/I(F)  compiler.  It  is  difficult  to  come  up  with  a  single  answer 
to  this  question.  There  are  certainly  many  alternative  ways  of 
implementing  PL/I  constructs  [Gries  71] .  The  issue  is  whether  the 
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cost  measure  terms  we  compute  are  really  characteristic  of  the 
System/360  hardware  or  whether  they  are  merely  characteristic 
of  the  PL/I(F)  compiler.  Our  knowledge  of  other  compilers  for 
PL/I  and  Algol  on  the  System/360  leads  us  to  conjecture  that 
most  of  the  value  of  each  cost  measure  term  can  be  directly  attributed 
to  the  System/360  hardware  and  that  an  independent  implementation 
of  Student  PL  for  the  System/360  would  be  forced  by  the  definition 
of  the  semantics  of  PL/I  into  lasing  roughly  equivalent  sequences 
of  machine  instructions  and  internal  data  representation. 

We  will  not  proceed  further  in  attempting  to  apportion  the 
responsibility  for  terms  in  the  cost  measure  between  the  compiler 
and  the  hardware  but  rather  leave  the  topic  for  future  consideration 
when  more  information  on  various  programming  language  implementations 
is  available.  In  this  chapter  we  restrict  ourselves  to  a  demon¬ 
stration  of  how  our  technique  can  be  used  to  compare  and  evaluate 
computers.  Our  choice  of  language  and  computers  was  made  for 
practical  reasons.  If  someone  wishes  to  compare  the  Student  PL 
machine  against  any  other  implementation  of  PL/I,  we  have  provided 
sufficient  detail  about  our  evaluation  experiment  so  that  he  might 
do  so. 
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6.3  The  Evaluation  Experiment 

The  first  steps  in  the  evaluation  process  are  to  select  a  representative 
collection  of  programs  and  to  construct  a  set  of  programming  language 
fragments  which: 

1)  cover  the  programming  language  constructs  used  in 
the  collection  of  programs, 

2)  do  not  have  overlapping  object  program  images 
on  any  of  the  computers  being  evaluated, 

3)  do  not  have  object  program  images  containing 
data  dependent  loops  on  any  of  the  computers 
being  evaluated. 

We  choose  to  use  the  collection  of  959  Student  PL  programs  described 
in  Chapter  5. 

If  the  set  of  language  fragments  completely  covers  the  set  of  programming 
language  constructs  which  actually  appear  in  the  collection  of  programs 
then  the  value  of  the  cost  measure  we  calculate  will  perfectly 
describe  the  characteristics  of  the  program  collection.  However,  in 
practice,  a  complete  covering  includes  many  fragments  which  occur  with 
extremely  low  frequency  in  the  programs  and  which  make  a  negligible 
contribution  to  the  value  of  the  cost  measure.  To  reduce  the 
effort  involved  in  evaluating  performance  it  is  convenient  to  compute 
the  cost  measure: 


M’CP)  -  +  E^  with  m'Cp)  »  E 

r(P) 


(P) 


where  is  the  measure  described  in  Section  2.4  and  E  is  an 


(P) 


error  term  due  to  an  incomplete  covering  of  the  sample  programs.  If 

>>  E^  then  M  ^  is  a  good  approximation  to  .  We  will 

(P) 


M 


discuss  later  some  ways  of  estimating  the  magnitude  of  E 
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By  examining  the  object  forms  of  the  student  programs  on  the 
computers  we  constructed  the  set  of  programming  language  fragments 
listed  in  Table  6.3.1.  The  translator  from  Student  PL  into  Student 
PL  Machine  language  was  modified  to  tabulate  the  static  occurrences 
of  fragments  and  to  emit  instructions  to  tabulate  the  dynamic  occurrences. 
The  959  student  programs  were  then  run  through  the  modified  translator- 
interpreter  to  obtain  the  static  and  dynamic  occurrences  tabulated  in 
Table  6.3.1. 

The  next  step  in  the  evaluation  process  is  to  associate  with  each 
programming  language  fragment,  values  for  each  term  in  the  cost 
measure  for  both  computers.  This  tedious  but  straightforward 
process  involves  examining  the  object  program  image  of  each  fragment 
and  tabulating  the  appropriate  quantity  for  each  term.  Consider, 
for  example,  fragment  number  208  -  access  to  the  value  of  an  element  of 
a  one  dimensional  array.  An  example  of  the  fragment  and  the  instructions 
used  to  implement  it  on  both  computers  are  given  in  Figure  6.3.1. 
Inspection  of  the  two  instruction  sequences  leads  to  the 
tabulations  in  Table  6. 3. 2.  In  tabulating  terms  for  the  language 
fragments  it  was  necessary  to  make  some  simplifying  assumptions  for  the 
purpose  of  removing  data  dependencies  and/or  simplifying  the  tabulation 
task.  These  assumptions  are  listed  in  Table  6.3.3. 
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Fragment 

Fragment 

Static 

Dynamic 

Number 

Description 

Occurrences 

Occurrences 

1 

Main  Program  overhead 
program  initialization 

959 

959 

2 

program  termination 

959 

423 

3 

intrinsic  functions /program 

Note  1 

Note  1 

4 

Statement  Number  Identification 

59331 

1254619 

5 

Statement  Label 

60 

460 

6 

Null  Statement 

47 

1511 

7 

Conditional  Statement 

IF-THEN 

3000 

8 

IF-THEN  (expression  =  false) 

- 

154197 

9 

IF-THEN  (expression  =  true) 

- 

56350 

10 

IF-THEN-ELSE 

1308 

- 

11 

IF-THEN-ELSE  (false) 

60331 

12 

IF-THEN-ELSE  (true) 

27423 

13 

BEGIN  END  Block 
initialization 

69 

61 

14 

termination 

69 

29 

15 

DO  Groups 

head  of  simple  DO 

1195 

44304 

16 

end  of  simple  DO 

1195 

44123 

17 

head  of  DO  WHILE 

1256 

5782 

18 

test  in  DO  WHILE 

1256 

45231 

19 

end  of  DO  WHILE 

1256 

39277 

20 

head  and  1st  expression  in 

DO  v  =  lis t-of-expressions 

35 

9  74 

21 

each  additional  expression 

52 

566 

22 

end  of  DO  v  =  lis t-of-expressions 

35 

1537 

23 

head  of  DO  v  =  e  [TO  e]  [BY  e] 

3883 

22775 

24 

saving  step  and  limit 

3970 

24330 

25 

testing  against  limit 

3888 

184439 

26 

incrementing  control  variable 

3871 

161675 

27 

end  of  DO  v  =  [TO  e]  [BY  e] 

3871 

161675 

28 

additional  for  WHILE  clause 

48 

1394 

Table  6.3.1  Programming  Language  Fragments 


1.  The  intrinsic  functions  called  from  an  object  program  vary. 
See  text  for  a  discussion  of  intrinsic  functions  accounting. 
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Fragment 

Fragment 

Static 

Dynamic 

Number 

Description 

Occurrences 

Occurrences 

Functions 

and  Procedures 

29 

head  of  procedure 

510 

23061 

30 

end  of  procedure 

510 

22464 

31 

head  of 

function  procedure 

91 

3536 

32 

end  of 

function  procedure 

91 

38 

33 

general  parameter  overhead 

223 

13370 

34 

overhead  for  FIXED  scalar  parameter  344 

26810 

35 

tt 

"  "  array  " 

59 

225 

36 

tf 

"  BIT  scalar 

0 

0 

37 

It 

"  "  array  " 

0 

0 

38 

II 

"  FLOAT  scalar 

37 

563 

39 

ft 

"  "  array  " 

0 

0 

40 

tf 

"  CHARACTER  scalar 

parameter 

54 

1368 

41 

M 

"  CHARACTER  array 

parameter 

0 

0 

DECLARE  Statement 


42 

BIT  scalar  variable 

12 

12 

43 

BIT  1  dimensional  array 

0 

0 

44 

BIT  2  dimensional  array 

0 

0 

45 

FIXED  scalar  variable 

5524 

33771 

46 

FIXED  1  dimensional  array 

819 

841 

47 

tt  2  ff  ft 

343 

480 

48 

FLOAT  scalar  variable 

2133 

8462 

49 

"  1  dimensional  array 

55 

55 

50 

"  2  dimensional  array 

19 

19 

51 

CHARACTER  scalar  variable 

1825 

4509 

52 

"  1  dimensional  array 

100 

107 

53 

m  2  t»  t» 

70 

96 

Assignment  Statement  -  BIT  variables 

54 

scalar  =  constant 

23 

98 

55 

scalar  =  scalar 

0 

0 

56 

scalar  =  expression 

4 

4 

57 

1  dimensional  array  element 

on  LHS 

0 

0 

58 

2  it  tt  »t 

n  ti 

0 

0 

59 

1  "  "  on  LHS 

-  initial 

0 

0 

60 

J  tf  tt  tf  95 

-  element 

0 

0 

61 

2  tt  tt  tt  tt 

-  initial 

0 

0 

62 

2  tt  tt  tt  tt 

-  row 

0 

0 

63 

2  tt  ft  tt  ft 

-  element 

0 

0 

Table  6.3.1  Programming  Language 

Fragments 

(cont.) 
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Fragment 

Fragment 

Static 

Number 

Description 

Occurrences 

Assignment  Statement 

-  FIXED 

64 

scalar  =  constant 

3900 

65 

scalar  =  scalar 

516 

66 

scalar  =  expression 

5575 

67 

1  dimensional  array 

element  on  LHS 

1038 

68 

2  "  " 

ii  it  it 

2131 

69 

2  M  II 

on  LHS-initial 

697 

70 

2  ii  it 

"  -element 

- 

71 

2  "  " 

"  "  -initial 

377 

72 

2  "  " 

"  "  -row 

- 

73 

2  "  " 

"  "  -element 

- 

Assignment  Statement 

-  FLOAT 

74 

scalar  =  constant 

509 

75 

scalar  =  scalar 

161 

76 

scalar  =  expression 

2407 

77 

1  dimensional  array 

element  on  LHS 

62 

78 

2  "  " 

tf  1!  II 

25 

79 

2  ii  it 

on  LHS-initial 

7 

80 

2  ii  ii 

"  "  -element 

- 

81 

•  2  "  " 

"  "  -initial 

2 

82 

2  "  " 

"  "  -row 

- 

83 

2  ii  it 

"  "  -element 

- 

Assignment  Statement  - 

CHARACTER 

84 

scalar  =  constant 

1054 

85 

scalar  =  scalar 

580 

86 

scalar  =  expression 

775 

87 

1  dimensional  array 

element  on  LHS 

340 

88 

2  "  " 

If  II  II 

213 

89 

2  ii  ii 

on  LHS-initial 

49 

90 

it  ii 

"  "  -element 

- 

91 

2  "  " 

"  "  -initial 

40 

92 

2  "  " 

"  "  -row 

- 

93 

2  ii  it 

"  "  -element 

- 

GO  TO  Statement 

94 

forward  GO  TO 

73 

95 

backward  GO  TO 

55 

96 

GO  TO  leaving  block 

or  procedure 

9 

Table  6.3.1  Programming  Language  Fragments  (cont.) 


Dynamic 

Occurrences 


12160 

10244 

118863 

20814 

43681 

671 

10047 

1231 

8070 

59409 


1283 

7455 

27180 

1355 

408 

6 

288 

2 

14 

98 


21251 

414C9 

25267 

3283 

7339 

104 

2073 

31 

103 

761 


3146 

189 

0 


135 


Fragment 

Fragment 

Static 

Dynami 

Number 

Description 

RETURN  Statement 

Occurrences 

Occurr 

97 

no  expression 

20 

468 

98 

BIT  expression 

0 

0 

99 

FIXED  expression 

29 

1588 

100 

FLOAT  expression 

37 

560 

101 

CHARACTER  expression 

CALL  Statement 

28 

1346 

102 

no  parameters 

702 

12294 

103 

with  parameters 

ALLOCATE  Statement 

472 

11010 

104 

BIT  1  dimensional  array  -  initial 

0 

0 

105 

m  j  it 

"  -  element 

0 

0 

106 

"  2  " 

"  -  initial 

0 

0 

107 

"  2  " 

"  -  element 

0 

0 

108 

FIXED  1  dimensional 

array-initial 

760 

750 

109 

II  ^  M 

"  -element 

- 

11616 

110 

"  2  " 

"  -initial 

311 

320 

111 

"  2  " 

"  -element 

- 

22503 

112 

FLOAT  1  " 

”  -initial 

55 

55 

113 

it  2  ii 

"  -element 

- 

692 

114 

it  2  " 

"  -initial 

18 

18 

115 

"  2  " 

"  -element 

- 

1377 

116 

CHARACTER  1  " 

"  -initial 

100 

107 

117 

ii  i  ii 

"  -element 

- 

1017 

118 

"  2  " 

"  -initial 

68 

96 

119 

"  2  " 

"  -element 

- 

27503 

120 

extra  for  implicit 

lower  bound 

1412 

1455 

121 

extra  for  explicit 

lower  bound 

300 

326 

122 

non- constant  bound 

BIT  array 

0 

0 

123 

IT  If  II 

FIXED  array 

24 

27 

124 

If  II  II 

FLOAT 

4 

4 

125 

II  II  17 

FREE  Statement 

CHARACTER  array 

41 

48 

126 

BIT  array 

0 

0 

127 

FIXED  array 

0 

0 

128 

FLOAT  array 

0 

0 

129 

CHARACTER  array 

0 

0 

130 

J  operator 

369 

32058 

131 

operator 

593 

46178 

132 

”7  operator 

21 

1474 

Table  6.3.1  Programming  Language  Fragments  (cont.) 
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Fragment 

Fragment 

Static 

Dynamic 

Number 

Description 

Relational  operators 

Occurrences 

Occurrences 

133 

BIT  scalar  :  scalar 

2 

2 

134 

"  "  :  expression 

0 

0 

135 

"  expression  :  scalar 

0 

0 

136 

"  "  :  expression 

0 

0 

137 

FIXED  scalar  :  scalar 

4103 

282736 

138 

"  scalar  :  expression 

138 

10575 

139 

"  expression  :  scalar 

533 

41015 

140 

"  expression  :  expression 

104 

8884 

141 

FLOAT  scalar  :  scalar 

514 

24382 

142 

"  "  :  expression 

33 

4016 

143 

"  expression  :  scalar 

169 

5608 

144 

"  expression  :  expression 

15 

2677 

145 

CHARACTER  scalar  :  scalar 

697 

27903 

146 

"  scalar  :  expression 

5 

128 

147 

"  expression  :  scalar 

74 

7208 

148 

"  expression  :  expression 

(|  operator 

1 

17 

149 

scalar  )l  scalar 

8452 

87938 

150 

scalar  !|  expression 

1621 

9433 

151 

expression  11  scalar 

5024 

11585 

152 

expression  U  expression 

+  operator  (binary) 

2608 

8410 

153 

FIXED  scalar  operands 

4913 

149938 

154 

FIXED  expression  operands 

29 

170 

155 

FLOAT  scalar  operands 

928 

17788 

156 

FLOAT  expression  operands 

-  operator  (unary) 

0 

0 

157 

FIXED  scalar  operand 

857 

39310 

158 

FIXED  expression  operands 

0 

0 

159 

FLOAT  scalar  operands 

2 

0 

160 

FLOAT  expression  operands 

-  operator  (binary) 

0 

0 

161 

FIXED  scalar  operands 

2094 

56525 

162 

FIXED  expression  operands 

56 

501 

163 

FLOAT  scalar  operands 

589 

6050 

164 

FLOAT  expression  operands 

*  operator 

20 

134 

165 

FIXED  scalar  operands 

469 

4088 

166 

FIXED  expression  operands 

54 

163 

167 

FLOAT  scalar  operands 

514 

9091 

168 

FLOAT  expression  operands 

117 

1608 

Table  6.3.1  Programming  Language  Fragments  (cont.) 
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169 

170 

171 

172 

173 

174 

175 

176 

177 

178 

179 

180 

181 

182 

183 

184 

185 

186 

187 

188 

189 

190 

191 

192 

193 

194 

195 

196 

197 

19  8 

199 

200 


Fragment 

Static 

Dynamic 

Description 

Occurrences 

Occurrences 

/  operator 

FIXED  scalar  operands 

468 

1597 

FIXED  expression  operands 

0 

0 

FLOAT  scalar  operands 

914 

2328 

FLOAT  expression  operands 

184 

407 

**  operator 

FIXED  **  FIXED  constant 

138 

604 

FIXED  **  FIXED  other 

497 

16735 

FIXED  **  FLOAT 

0 

0 

FLOAT  **  FIXED  constant 

528 

4253 

FLOAT  **  FIXED  other 

4 

4 

FLOAT  **  FLOAT 

2 

2 

Type  Conversions 

BIT  to  FIXED 

18 

1734 

BIT  to  FLOAT 

3 

7 

BIT  to  CHARACTER 

20 

25 

FIXED  to  BIT 

0 

0 

FIXED  to  FLOAT 

2132 

39068 

FIXED  to  CHARACTER 

5421 

36251 

FLOAT  to  BIT 

0 

0 

FLOAT  to  FIXED 

0 

0 

FLOAT  to  CHARACTER 

1546 

4732 

CHARACTER  to  BIT 

0 

0 

CHARACTER  to  FIXED 

0 

0 

CHARACTER  to  FLOAT 

0 

0 

Use  of  Constants 

FIXED  (  <  64  )  assignment  stmt 

1273 

26324 

FIXED  (  <  64  )  other 

50072 

820137 

FIXED  (  other  )  assignment  stmt 

38 

129 

FIXED  (  other  )  other 

0 

0 

FLOAT  assignment  statement 

215 

1357 

FLOAT  other 

705 

14982 

BIT  assignment  statement 

14 

98 

BIT  other 

26 

235 

CHARACTER  assignment  statement 

95 

29258 

CHARACTER  other 

13783 

109092 

Table  6.3.1  Programming  Language  Fragments  (cont.) 
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201 

202 

203 

204 

204 

206 

207 

208 

209 

210 

211 

212 

213 

214 

215 

216 

217 

218 

219 

220 

221 

222 

223 

224 

225 

226 

227 


Fragment 

Static 

Dynami c 

Description 

Occurrences 

Occurrences 

Access  to  a  BIT  variable 

scalar-RHS  of  assignment 

0 

0 

scalar-other 

13 

1618 

1  dimensional  array  element 

0 

0 

2  n  i»  m 

0 

0 

up level  references 

0 

0 

Access  to  a  FIXED  variable 

scalar-RHS  of  assignment 

3135 

12265 

scalar- other 

29681 

1091044 

1  dimensional  array  element 

4357 

42458 

2  II  M  It 

3172 

294876 

uplevel  references 

6190 

383496 

Access  to  a  FLOAT  variable 

scalar-RHS  of  assignment 

972 

7476 

scalar- other 

4720 

52847 

1  dimensional  array  element 

210 

6553 

2  M  II  II 

248 

24183 

uplevel  references 

207 

11651 

Access  to  a  CHARACTER  variable 

scalar-RHS  of  assignment 

4026 

42911 

scalar-other 

10493 

140618 

1  dimensional  array  element 

383 

10822 

2  ii  ii  ii 

167 

7458 

uplevel  references 

9472 

59520 

Parameter  Passing  Overhead-BIT 

User  Procedures 

constant 

0 

0 

scalar  variable 

0 

0 

1  dimensional  array  element 

0 

0 

2  it  it  it 

0 

0 

2  ii  ii 

0 

0 

2  "  " 

0 

0 

expression 

0 

0 

Table  6.3.1  Programming  Lanaguage  Fragments  (cont.) 
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228 

229 

230 

231 

232 

233 

234 

235 

236 

237 

238 

239 

240 

241 

242 

243 

244 

245 

246 

247 

248 

249 

250 

251 

252 

253 

254 

255 

256 

257 

258 

259 

260 

261 


Fragment 

Static 

Dynamic 

Description 

Occurrences 

Occurrences 

Parameter  Passing  Overhead-FIXED 

User  procedures 
constant 

116 

917 

scalar  variable 

107 

2157 

1  dimensional  array 

element 

90 

1721 

2  "  " 

t? 

53 

1866 

1  H  It 

99 

68 

2  it  " 

30 

159 

expression 

131 

1951 

Built-in  functions 

constant 

10237 

51376 

scalar  variable 

849 

36259 

1  dimensional  array 

element 

653 

1570 

2  H  " 

ft 

2 

31 

expression 

1268 

31 765 

Parameter  Passing  Overhead- FLOAT 

User  procedures 
constant 

3 

2 

scalar  variable 

0 

0 

1  dimensional  array 

element 

0 

0 

2  "  " 

ft 

0 

0 

it  m 

0 

0 

2  M  " 

0 

0 

expression 

0 

0 

Built-in  functions 

constant 

0 

0 

scalar  variable 

275 

581 

1  dimensional  array 

element 

16 

66 

2  "  " 

ft 

0 

0 

expression 

468 

1431 

Parameter  Passing  Overhead- CHARACTER 

User  procedures 
constant 

24 

571 

scalar  variable 

148 

1014 

1  dimensional  array 

element 

17 

29 

H  H 

m 

0 

0 

^  n  u 

0 

0 

2  "  " 

0 

0 

expression 

11 

137 

Built-in  functions 

constant 

422 

20540 

scalar  variable 

7048 

87863 

1  dimensional  array 

element 

43 

744 

2  "  " 

tv 

0 

0 

expression 

47 

2611 

Table  6.3.1  Programming  Language  Fragments  (cont.) 
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Fragment 

Number 


Fragment 

Description 

Function  calls 
User  functions 


Static 

Occurrences 


Dynamic 

Occurrences 


264 

BIT,  no  parameters 

0 

0 

265 

BIT,  with  parameters 

0 

0 

266 

FIXED,  no  parameters 

38 

1340 

267 

FIXED,  with  parameters 

48 

718 

268 

FLOAT,  no  parameters 

0 

0 

269 

FLOAT,  with  parameters 

70 

589 

270 

CHARACTER,  no  parameters 

5 

10 

271 

CHARACTER,  with  parameters 

47 

1445 

Built-in  functions 

272 

random 

513 

14206 

273 

substr,  2  arguments 

446 

17481 

274 

substr,  3  arguments. 

5837 

42524 

275 

index 

530 

21219 

276 

abs 

25 

424 

277 

sqrt 

656 

629 

278 

fixed 

46 

1342 

279 

round 

39 

36 

280 

float 

887 

4058 

281 

character 

18 

188 

282 

length 

665 

10672 

Input  and  Output 

283 

use  of  pseudo -variable  INPUT 

2062 

14848 

284 

use  of  pseudo-variable  OUTPUT 

8665 

30559 

Table  6.3.1  Programming  Language  Fragments  (cont.) 
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<variable>  (  <expression>  ) 


a.  fragment  208 


NAME  <variable> 

^  <expression> 

SUBSEVAL  1 


b.  Student  PL  Machine  Code 


) 

<expression>  -> 

Re 

L 

Ra,PR. .variable 

descriptor  address 

CH 

Re,8(0,Ra) 

check  upper  bound 

BALR 

Rp,0 

BC 

2 , LERR 

CH 

Re,10(0,Ra) 

check  lower  bound 

BALR 

Rp,0 

BC 

11, LOK 

LERR 

LA 

Rb ,PR. . IHEQERR 

subs cript range  error 

MVI 

0 (Rb) ,X ' 30 ' 

L 

15 , A. . IHEERRB 

BALR 

14,15 

LOK 

STH 

Re  ,WS 

working  storage 

L 

Ra,PR. .variable 

descriptor  address 

L 

Re,4(0,Ra) 

MH 

Re,WS 

L 

Rp,0(0,Ra) 

base  address  of  array 

L 

Rc,0(Re,Rp) 

value  of  element  to  Rc 

c.  System/ 360  code 


Figure  6.3.1  Example  of  Object  Program  Images 
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term 

Student^PL 

Machine 

System/ 360^ 

al 

25.3 

496 

instruction  bits 

a2 

0 

0 

data  bits 

a3 

2 

13 

instruction  memory  accesses 

a4 

9 

9 

data  memory  accesses 

a5 

25.3 

384 

instruction  bits  accessed 

a6 

408 

224 

data  bits  accessed 

Table  6.3.2 

Tabulation  for  Fragment  208 

1.  For  a  description  of  the  assumptions  underlying  the 

tabulations  see  Table  6.3.3  and  the  notes  accompanying  Tables 
6.3.4  and  6.3.5. 
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1. 


The  two  systems  should  run  programs  under  as  nearly  identical 
conditions  as  possible.  PL/I(F)  conditions  were  enabled  to  check 
in  software  for  errors  detected  by  the  Student  PL  machine  hardware 
(SUBSCRIPTRANGE,  OVERFLOW,  ZERODIVIDE,  UNDERFLOW,  STRINGRANGE,  etc.). 

2.  There  is  no  condition  in  PL/I(F)  which  can  be  set  to  check  for  use 

of  an  undefined  value  so  such  checking  was  not  included.  The  shortest 
code  sequence  known  to  the  author  for  doing  this  checking  on  the 
System/360  is: 

L  r,<variable> 

LPR  r,r 

where  all  variables  are  initialized  to  the  largest  possible  negative 

number.  If  the  cost  measure  terms  for  this  sequence  were  added 

to  the  System/360  tabulation  at  appropriate  places  the  total  change 

in  the  tabulation  would  be  a,  ,a  •  +7%  ar:  +6%,  and  a., a,:  +4%. 

1 5  3  ’5  5  4’  6 

3.  Since  the  Student  PL  machine  was  being  simulated  on  a  System/360, 
programs  whose  termination  depended  on  the  arithmetic  properties  of 
the  computer  would  terminate  at  the  same  point  on  both  machines.  Thus 
we  could  use  the  same  set  of  dynamic  occurrences  to  compute  the 

cost  measure  for  the  two  machines. 

4.  Since  error  handling,  builtin  functions,  and  input/output  were  not 
specified  for  the  Student  PL  machine  it  would  not  be  fair  to  penalize 
the  System/ 360  for  providing  these  facilities.  Thus,  for  both  computers, 
only  the  attributes  of  the  instruction  sequences  used  to  link  to 

error  routines,  builtin  functions,  and  input/output  routines  were 
tabulated. 

5.  To  compensate  the  Student  PL  machine  for  the  line  number  table  (Section 
5.4)  a  number  of  bits  equal  to  the  total  size  of  the  Student  PL  programs 
(3,135,842  bits)  was  added  to  a9  for  the  Student  PL  machine.  This 
quantity  is  a  conservative  upper  bound  on  the  size  of  the  line  number  table. 

6.  For  a  number  of  fragments,  the  System/360  object  program  image  included 
calls  on  intrinsic  subroutines.  The  average  dynamic  attributes  of  the 
subroutine  were  included  in  a^  ^  for  the  fragment.  The  space  required 
by  the  subroutine  was  included  m  a^  once  for  each  program  in  which 
the  fragment  occurred. 

7.  To  resolve  a  data  dependency,  the  average  length  of  all  character 
string  operands  was  taken  to  be  16  characters. 

8.  The  depth  of  nesting  for  display  update  was  assumed  to  be  2. 

9.  All  array  assignment  statements  were  assumed  to  have  a  scalar  value 
on  the  RHS. 

Table  6.3.3  Experiment  Assumptions 
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The  process  of  tabulating  terms  for  each  programming  language  frag¬ 
ments  was  repeated  for  each  fragment  and  both  computers  being  evaluated. 

The  resulting  tabulations  (the  array  of  Section  2.4)  are  listed  in 

Tables  6.3.4  and  6.3.5.  Once  this  information  had  been  obtained,  the 
summations  indicated  above  were  performed  to  obtain  values  for  each  term 
of  the  cost  measure. 

Table  6.3.6  contains  a  summary  of  the  cost  measure  calculation. 

It  is  interesting  to  note  how  the  values  in  this  table  characterize  the 
two  machines.  The  Student  PL  machine,  which  was  designed  to  minimize  the 
space  required  to  store  programs,  has  a  large  advantage  in  terms  a^  (bits 
of  program) ,  and  a^  (bits  of  program  fetched) .  The  elaborate  data 
structures  of  the  Student  PL  machine  mean  that  it  requires  slightly  fewer 
memory  references  to  fetch  data  (a^)  but  that  the  number  of  bits 
accessed  (a^)  is  large.  Note  2  to  Table  6.3.4  indicates  why 
the  Student  PL  machine  has  a  relatively  poor  showing  on  terms  a^  and  a^.  It 
is  well  known  [Burroughs  1961]  that  a  better  stack  management  algorithm 
is  to  keep  track  of  valid  entries  on  top  of  a  stack  and  to  fill  the  top 
of  stack  registers  from  memory  only  when  necessary.  However  this  stack 
management  algorithm  is  much  harder  to  analyze,  so  it  was  not  used  for 
our  case  study.  The  System/360  does  relatively  better  on  term  a^  because 
many  fragments  which  occur  frequently  are  implemented  by  a  single  instruction. 
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Fragment 

Number 

Attributes 

al 

a2 

1 

57.3 

40 

2 

32 

0 

3 

0 

0 

4 

0 

0 

5 

0 

0 

6 

0 

0 

7 

17.3 

40 

8 

0 

0 

9 

0 

0 

10 

17.3 

80 

11 

0 

0 

12 

0 

0 

13 

41.3 

68 

14 

32 

0 

15 

0 

0 

16 

0 

0 

17 

16 

40 

18 

24 

40 

19 

8 

0 

20 

49.3 

80 

21 

24 

0 

22 

0 

0 

23 

25.3 

40 

24 

0 

0 

25 

8 

0 

26 

8 

0 

27 

0 

0 

28 

8 

0 

29 

16 

40 

30 

24 

0 

31 

16 

40 

32 

32 

0 

33-41 

0 

0 

42-53 

0 

112 

54-56 

17.3 

0 

57-58 

33.3 

0 

59 

33.3 

0 

60 

0 

0 

61 

33.3 

0 

62 

0 

0 

63 

0 

0 

64-66 

17.3 

0 

67-68 

33.3 

0 

69 

33.3 

0 

70 

0 

0 

71 

33.3 

0 

72 

0 

0 

73 

0 

0 

a3 

a4 

a5 

a6 

4 

13 

57.3 

415 

3 

11 

32 

241 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

2 

2 

17.3 

80 

2 

4 

17.3 

181 

0 

0 

0 

0 

2 

5 

17.3 

221 

2 

5 

17.3 

221 

3 

13 

41.3 

415 

3 

12 

32 

313 

0 

0 

0 

0 

0 

0 

0 

0 

2 

6 

16 

237 

3 

6 

24 

237 

1 

0 

8 

0 

6 

17 

49.3 

586 

3 

9 

24 

325 

0 

1 

0 

61 

3 

8 

25.3 

261 

0 

0 

0 

0 

1 

4 

8 

128 

1 

4 

8 

128 

0 

1 

0 

61 

1 

1 

8 

40 

1 

0 

16 

0 

2 

10 

24 

233 

1 

0 

16 

0 

3 

11 

32 

273 

0 

0 

0 

0 

0 

2 

0 

80 

2 

8 

17,3 

392 

3 

5 

33.3 

304 

3 

1 

33.3 

192 

0 

1 

0 

40 

3 

1 

33.3 

288 

0 

0 

0 

0 

0 

1 

0 

40 

2 

8 

17,3 

392 

3 

5 

33.3 

304 

3 

1 

33.3 

192 

0 

1 

0 

40 

3 

1 

33.3 

288 

0 

0 

0 

0 

0 

1 

0 

40 

Table  6.3.4  Fragment  Attribute  Matrix  for  Student  PL  Machine 
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Fragment  Attributes 


Number 

a. 

a 

a. 

a . 

3-r- 

a. 

1 

2 

3 

4 

5 

6 

74-76 

17.3 

0 

2 

8 

17.3 

392 

77-78 

33.3 

0 

3 

5 

33.3 

304 

79 

33.3 

0 

3 

1 

33.3 

192 

80 

0 

0 

0 

1 

0 

40 

81 

33.3 

0 

3 

1 

33.3 

288 

82 

0 

0 

0 

0 

0 

0 

83 

0 

0 

0 

1 

0 

40 

84-86 

17.3 

0 

2 

8 

17.3 

392 

87-88 

33.3 

0 

3 

5 

33.3 

304 

89 

33.3 

0 

3 

1 

33.3 

192 

90 

0 

0 

0 

1 

0 

40 

91 

33.3 

0 

3 

1 

33.3 

288 

92 

0 

0 

0 

0 

0 

0 

93 

0 

0 

0 

1 

0 

40 

94-95 

17.3 

0 

2 

5 

17.3 

144 

96 

50.6 

40 

5 

20 

50.6 

521 

97 

24 

0 

2 

11 

24 

273 

98-101 

16 

0 

1 

10 

16 

233 

102-103 

33.3 

0 

3 

13 

33.3 

415 

104 

25.3 

112 

2 

13 

25.3 

440 

105 

0 

40 

0 

1 

0 

8 

106 

25.3 

288 

2 

13 

25.3 

536 

107 

0 

40 

0 

1 

0 

8 

108 

25.3 

112 

2 

13 

25.3 

440 

109 

0 

40 

0 

1 

0 

8 

110 

25.3 

288 

2 

13 

25.3 

536 

111 

0 

40 

0 

1 

0 

8 

112 

25.3 

112 

2 

13 

25.3 

440 

113 

0 

40 

0 

1 

0 

8 

114 

25.3 

288 

2 

13 

25.3 

536 

115 

0 

40 

0 

1 

0 

8 

116 

25.3 

112 

2 

13 

25.3 

440 

117 

0 

168 

0 

1 

0 

8 

118 

25.3 

288 

2 

13 

25.3 

536 

119 

0 

168 

0 

1 

0 

8 

120 

8 

0 

1 

1 

8 

40 

121 

8 

0 

1 

0 

8 

0 

122-125 

0 

0 

0 

0 

0 

0 

126-129 

17.3 

0 

2 

6 

17.3 

128 

130-131 

8 

0 

1 

1 

8 

40 

132 

8 

0 

1 

0 

8 

0 

133-148 

8 

0 

1 

1 

8 

40 

149-152 

8 

0 

1 

5 

8 

104 

153-156 

8 

0 

1 

1 

8 

40 

157-160 

8 

0 

1 

0 

8 

0 

161-178 

8 

0 

1 

1 

8 

40 

179-190 

0 

0 

0 

0 

0 

0 

191-192 

8 

0 

1 

1 

8 

40 

193-198 

8 

40 

1 

2 

8 

80 

199-200 

8 

168 

1 

2 

8 

80 

Table  6.3.4  Fragment  Attribute  Matrix  for 
Student  PL  Machine  (cont.) 


147 


Fragment  Attributes 


Number 

ai 

a2 

a3 

a4 

a5 

a6 

201-202 

8 

0 

1 

3 

8 

96 

203 

25.3 

0 

2 

9 

25.3 

408 

204 

25.3 

0 

2 

9 

25.3 

504 

205 

0 

0 

0 

0 

0 

0 

206-207 

8 

0 

1 

3 

8 

96 

208 

25.3 

0 

2 

9 

25.3 

408 

209 

25.3 

0 

2 

9 

25.3 

504 

210 

0 

0 

0 

0 

0 

0 

211-212 

8 

0 

1 

3 

8 

96 

213 

25.3 

0 

2 

9 

25.3 

408 

214 

25.3 

0 

2 

9 

25.3 

504 

215 

0 

0 

0 

0 

0 

0 

216-217 

8 

0 

1 

3 

8 

96 

218 

25.3 

0 

2 

9 

25.3 

408 

219 

25.3 

0 

2 

9 

25.3 

504 

220 

0 

0 

0 

0 

0 

0 

221-227 

16 

0 

1 

4 

16 

90 

228-234 

16 

0 

1 

4 

16 

90 

235-239 

0 

0 

0 

0 

0 

0 

240-246 

16 

0 

1 

4 

16 

90 

247-251 

0 

0 

0 

0 

0 

0 

252-258 

16 

0 

1 

4 

16 

90 

259-263 

0 

0 

0 

0 

0 

0 

264-271 

25.3 

0 

2 

12 

25.3 

375 

272-282 

24 

0 

2 

1 

24 

40 

283 

24 

0 

2 

1 

24 

40 

284 

25.3 

0 

2 

4 

25.3 

104 

Notes : 

1.  All  registers,  display,  ds[dsp],  ds[dsp-l],  ps[psp],  and  ss[ssp] 
are  assumed  to  be  accessable  without  a  memory  reference. 

2.  All  stacks  are  assumed  to  be  kept  full,  thus  each  stack  push  or 
pop  counts  as  a  memory  reference. 

3.  The  NAME  instruction  was  assigned  a  length  of  9*3  bits  to  compensate 
for  the  observed  distribution  of  short  and  long  NAME  instructions. 
Similar  compensation  was  not  necessary  for  the  LOAD  instructions  due 
to  the  rarety  of  the  long  form. 

4.  Following  an  indirect  address  chain  was  assumed  to  require  1 
reference  to  ds  if  initiated  from  ds[dsp]  or  ds[dsp-l]. 
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Fragment 

Number 

Attributes 

a. 

a„ 

a. 

a . 

ar 

a.. 

1 

2 

3 

4 

5 

6 

1 

832 

112 

89 

93 

2624 

2648 

2 

48 

32 

71 

71 

1952 

1712 

3 

0 

0 

0 

0 

0 

0 

4 

32 

0 

1 

1 

32 

8 

5 

0 

0 

0 

0 

0 

0 

6 

0 

C 

0 

0 

0 

0 

7 

56 

0 

0 

0 

0 

0 

8 

0 

0 

2 

0 

56 

0 

9 

0 

0 

2 

0 

56 

0 

10 

96 

0 

0 

0 

0 

0 

11 

0 

0 

2 

0 

56 

0 

12 

0 

0 

4 

0 

112 

0 

13 

524 

96 

28 

33 

800 

824 

14 

48 

0 

16 

23 

464 

624 

15-17 

0 

0 

0 

0 

0 

0 

18 

80 

0 

3 

1 

80 

8 

19 

64 

32 

2 

1 

64 

32 

20 

80 

32 

5 

1 

80 

32 

21 

160 

0 

6 

2 

160 

40 

22 

48 

0 

2 

1 

48 

32 

23 

80 

0 

3 

1 

80 

32 

24 

0 

0 

0 

0 

0 

0 

25 

32 

0 

1 

0 

32 

0 

26 

0 

0 

0 

0 

0 

0 

27 

32 

32 

1 

1 

32 

32 

28 

48 

0 

2 

0 

48 

0 

29 

512 

64 

26 

27 

768 

776 

30 

576 

64 

28 

29 

832 

840 

31-32 

48 

0 

16 

23 

464 

624 

33 

80 

0 

2 

3 

80 

72 

34-40 

0 

32 

0 

0 

0 

0 

41 

112 

128 

3 

3 

112 

96 

42 

112 

64 

3 

3 

112 

96 

43 

0 

128 

0 

0 

0 

0 

44 

0 

192 

0 

0 

0 

0 

45 

0 

32 

0 

0 

0 

0 

46 

0 

96 

0 

0 

0 

0 

47 

0 

160 

0 

0 

0 

0 

48 

0 

32 

0 

0 

0 

0 

49 

0 

96 

0 

0 

0 

0 

50 

0 

160 

0 

0 

0 

0 

51 

112 

32824 

3 

3 

112 

96 

52 

0 

96 

0 

0 

0 

0 

53 

0 

160 

0 

0 

0 

0 

54 

24 

0 

0.5 

1 

24 

8 

55 

24 

0 

0.5 

1 

24 

8 

56 

48 

0 

1 

2 

48 

16 
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60 

61 

62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 

82 

83 

84 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 

00 

.01 


Attributes 


al 

a2 

a3 

a4 

a5 

912 

0 

91 

76 

2592 

1424 

0 

109 

85 

2992 

352 

8 

11 

9 

352 

1040 

0 

98 

79 

2720 

208 

64 

7 

6 

208 

496 

64 

15 

11 

496 

1712 

0 

119 

93 

3280 

24 

0 

0.5 

1 

24 

24 

0 

0.5 

1 

24 

32 

0 

1 

1 

32 

496 

0 

13 

9 

384 

976 

0 

26 

17 

752 

352 

64 

11 

9 

352 

592 

0 

15 

12 

480 

224 

64 

7 

6 

224 

576 

64 

18 

14 

576 

1104 

0 

27 

22 

880 

24 

0 

0.5 

1 

24 

24 

0 

0.5 

1 

24 

32 

0 

1 

1 

32 

496 

0 

13 

9 

384 

976 

0 

26 

17 

752 

352 

64 

11 

9 

352 

592 

0 

15 

12 

480 

224 

64 

7 

6 

224 

576 

64 

18 

14 

576 

1104 

0 

27 

22 

880 

56 

0 

1.5 

2 

56 

80 

0 

28 

31 

864 

80 

0 

28 

31 

864 

544 

0 

40 

39 

1216 

976 

0 

53 

47 

1536 

352 

64 

11 

10 

352 

640 

0 

41 

42 

1312 

240 

128 

8 

7 

240 

560 

0 

18 

12 

560 

1216 

0 

59 

52 

1776 

48 

0 

2 

0 

48 

64 

0 

2 

1 

64 

80 

32 

87 

77 

2496 

48 

0 

100 

103 

2752 

320 

0 

154 

145 

4240 

112 

0 

81 

66 

2244 

112 

0 

81 

66 

2244 

176 

0 

109 

96 

3072 

80 

0 

3 

1 

80 

112 

0 

4 

2 

112 

96 

128 

29 

43 

848 

0 

1 

0 

0 

0 

320 

112 

44 

39 

1200 

0 

1 

44 

39 

1200 
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2144 

2352 

256 

2152 

160 

296 

2552 

32 

32 

32 

224 

416 

256 

296 

160 

400 

544 

32 

32 

32 

224 

416 

256 

296 

160 

400 

544 

144 

1112 

1112 

1304 

1466 

288 

1376 

160 

304 

1632 

0 

32 

2288 

2960 

4168 

1888 

1888 

2968 

32 

40 

1760 

0 

2120 

2120 


Fragment 

Number 

Attributes 

a. 

a„ 

a„ 

a . 

a. 

a. 

1 

2 

3 

4 

5 

6 

57 

912 

0 

91 

76 

2592 

2144 

58 

1424 

0 

109 

85 

2992 

2352 

59 

352 

8 

11 

9 

352 

256 

60 

1040 

0 

98 

79 

2720 

2152 

61 

208 

64 

7 

6 

208 

160 

62 

496 

0 

15 

11 

496 

296 

63 

1712 

0 

119 

93 

3280 

2552 

64 

24 

0 

0.5 

1 

24 

32 

65 

24 

0 

0.5 

1 

24 

32 

66 

32 

0 

1 

1 

32 

32 

67 

496 

0 

13 

9 

384 

224 

68 

9  76 

0 

26 

17 

752 

416 

69 

352 

64 

11 

9 

352 

256 

70 

592 

0 

15 

12 

480 

296 

71 

224 

64 

7 

6 

224 

160 

72 

576 

64 

18 

14 

5  76 

400 

73 

1104 

0 

27 

22 

880 

544 

74 

24 

0 

0.5 

1 

24 

32 

75 

24 

0 

0.5 

1 

24 

32 

76 

32 

0 

1 

1 

32 

32 

77 

496 

0 

13 

9 

384 

224 

78 

976 

0 

26 

17 

752 

416 

79 

352 

64 

11 

9 

352 

256 

80 

592 

0 

15 

12 

480 

296 

81 

224 

64 

7 

6 

224 

160 

82 

576 

64 

18 

14 

576 

400 

83 

1104 

0 

27 

22 

880 

544 

84 

56 

0 

1.5 

2 

56 

144 

85 

80 

0 

28 

31 

864 

1112 

86 

80 

0 

28 

31 

864 

1112 

87 

544 

0 

40 

39 

1216 

1304 

88 

976 

0 

53 

47 

1536 

1466 

89 

352 

64 

11 

10 

352 

288 

90 

640 

0 

41 

42 

1312 

1376 

91 

240 

128 

8 

7 

240 

160 

92 

560 

0 

18 

12 

560 

304 

93 

1216 

0 

59 

52 

1776 

1632 

94 

48 

0 

2 

0 

48 

0 

95 

64 

0 

2 

1 

64 

32 

96 

80 

32 

87 

77 

2496 

2288 

97 

48 

0 

100 

103 

2752 

2960 

98 

320 

0 

154 

145 

4240 

4168 

99 

112 

0 

81 

66 

2244 

1888 

100 

112 

0 

81 

66 

2244 

1888 

101 

176 

0 

109 

96 

3072 

2968 

102 

80 

0 

3 

1 

80 

32 

103 

112 

0 

4 

2 

112 

40 

104 

96 

128 

29 

43 

848 

1760 

105 

0 

1 

0 

0 

0 

0 

106 

320 

112 

44 

39 

1200 

2120 

107 

0 

1 

44 

39 

1200 

2120 
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Fragment 

Number 

Attributes 

al 

a2 

a3 

a4 

a5 

a6 

108 

336 

96 

29 

43 

848 

1632 

109 

0 

32 

0 

0 

0 

0 

110 

336 

160 

29 

43 

848 

1888 

111 

0 

32 

0 

0 

0 

0 

112 

336 

96 

29 

43 

848 

1632 

113 

0 

32 

0 

0 

0 

0 

114 

336 

160 

29 

43 

848 

1888 

115 

0 

32 

0 

0 

0 

0 

116 

976 

128 

44 

51 

1264 

1984 

117 

0 

32824 

8 

4 

224 

128 

118 

1296 

192 

67 

64 

1936 

1992 

119 

0 

32824 

8 

4 

224 

128 

120 

0 

0 

0 

0 

0 

0 

121 

32 

0 

1 

1 

32 

16 

122-124 

208 

0 

169 

42 

5120 

1216 

125 

384 

0 

176 

43 

5296 

1248 

126-129 

80 

0 

19 

35 

512 

1080 

130-131 

96 

0 

2 

4 

96 

32 

132 

80 

0 

2 

3 

80 

24 

133 

192 

0 

7 

4 

192 

80 

134-135 

224 

0 

8 

5 

224 

88 

136 

256 

0 

9 

6 

256 

96 

137-138 

112 

0 

4 

2 

112 

16 

139-140 

128 

0 

5 

2 

128 

16 

141-142 

112 

0 

4 

2 

112 

16 

143-144 

128 

0 

5 

2 

128 

16 

145-148 

240 

0 

34 

33 

960 

1176 

149-152 

624 

352 

103 

104 

3104 

3648 

153 

0 

0 

0 

0 

0 

0 

154 

16 

0 

1 

0 

16 

0 

155 

0 

0 

0 

0 

0 

0 

156-160 

16 

0 

1 

0 

16 

0 

161 

0 

0 

0 

0 

0 

0 

162 

16 

0 

1 

0 

16 

0 

163 

0 

0 

0 

0 

0 

0 

164 

16 

0 

1 

0 

16 

0 

165 

32 

0 

1 

0 

32 

0 

166 

48 

0 

2 

0 

48 

0 

167 

0 

0 

0 

0 

0 

0 

168 

16 

0 

1 

0 

16 

0 

169 

32 

0 

1 

0 

32 

0 

170 

96 

0 

3 

0 

96 

64 

171 

0 

0 

0 

0 

0 

0 

172 

16 

0 

1 

0 

16 

0 

173 

388 

32 

66 

51 

1744 

1592 

174 

480 

32 

100 

75 

2624 

2344 

175 

560 

32 

98 

68 

2640 

2272 
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Fragment 

Number 

Attributes 

al 

a2 

a3 

a4 

a5 

a6 

176 

16 

0 

1 

0 

16 

0 

111 

144 

0 

37 

26 

928 

816 

178 

144 

0 

131 

101 

3504 

2928 

179 

176 

0 

70 

49 

1648 

1352 

180 

400 

32 

78 

56 

1872 

1584 

181 

176 

32 

34 

19 

944 

384 

182 

176 

32 

104 

82 

3040 

1952 

183 

160 

0 

6 

5 

160 

168 

184 

176 

32 

100 

143 

2816 

4096 

185 

176 

32 

44 

45 

1296 

1248 

186 

176 

32 

57 

43 

1536 

1232 

187 

176 

32 

104 

203 

3512 

5852 

188 

176 

32 

144 

159 

3420 

3640 

189 

176 

32 

129 

116 

3520 

3080 

190 

176 

32 

157 

151 

4224 

3900 

191 

24 

32 

0.5 

1 

24 

32 

192 

32 

32 

1 

1 

32 

32 

193 

24 

32 

0.5 

1 

24 

32 

194 

32 

32 

1 

1 

32 

32 

195 

24 

32 

0.5 

1 

24 

32 

196 

32 

32 

1 

1 

32 

32 

197-198 

24 

8 

0.5 

1 

24 

8 

199 

88 

160 

2.5 

2 

88 

20 

200 

32 

160 

1 

0 

32 

0 

201 

24 

0 

0.5 

1 

24 

8 

202 

48 

0 

1 

1 

48 

8 

203 

752 

0 

23 

13 

640 

288 

204 

1264 

0 

37 

21 

1040 

480 

205 

32 

0 

1 

1 

32 

32 

206 

24 

0 

0.5 

1 

24 

32 

207 

32 

0 

1 

1 

32 

32 

208 

496 

0 

13 

9 

384 

224 

209 

976 

0 

26 

17 

752 

416 

210 

32 

0 

1 

1 

32 

32 

211 

24 

0 

0.5 

1 

24 

32 

212 

32 

0 

1 

1 

32 

32 

213 

496 

0 

13 

9 

384 

224 

214 

976 

0 

26 

17 

752 

416 

215 

32 

0 

1 

1 

32 

32 

216-217 

32 

0 

1 

0 

32 

0 

218 

496 

0 

13 

8 

384 

192 

219 

976 

0 

26 

16 

752 

384 

220 

32 

0 

1 

1 

32 

32 

221 

112 

32 

3 

2.5 

112 

40 

222-224 

32 

0 

1 

1 

32 

32 

225-226 

176 

0 

6 

1 

144 

32 

227 

112 

0 

3 

3 

112 

48 

228 

112 

0 

3 

1.5 

112 

64 

229-231 

32 

0 

1 

1 

32 

32 
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Fragment 

Number 

Attributes 

al 

a2 

a3 

a4 

a5 

a6 

232-233 

176 

0 

6 

1 

144 

32 

234 

96 

0 

3 

2 

96 

64 

235-239 

32 

0 

1 

1 

32 

32 

240 

112 

0 

3 

1.5 

112 

64 

241-243 

32 

0 

1 

1 

32 

32 

244-245 

176 

0 

6 

1 

144 

32 

246 

96 

0 

3 

2 

96 

64 

247-251 

32 

0 

1 

1 

32 

32 

252 

688 

96 

100 

89 

2640 

3312 

253-255 

32 

0 

1 

1 

32 

32 

256-257 

176 

0 

6 

1 

144 

32 

258 

656 

96 

114 

no 

3392 

4336 

259 

48 

32 

1 

2 

48 

64 

260-262 

32 

0 

1 

1 

32 

32 

263 

656 

96 

114 

no 

3392 

4336 

264-265 

176 

32 

6 

3 

176 

72 

266-269 

176 

0 

6 

3 

176 

72 

270-271 

608 

64 

95 

87 

2560 

3304 

272 

176 

0 

6 

3 

176 

72 

273-274 

192 

32 

6 

4 

192 

96 

275 

144 

0 

5 

2 

144 

64 

276 

16 

0 

1 

0 

16 

0 

277 

144 

0 

5 

2 

144 

64 

278-279 

144 

0 

5 

1 

144 

32 

2  80 

192 

32 

7 

6 

192 

200 

281 

144 

0 

5 

1 

144 

32 

282 

32 

0 

1 

1 

32 

16 

283-284 

240 

64 

9 

4 

240 

104 

Table  6.3.5  Fragment  Attribute  Matrix  for  System/360  (cont.) 
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Term 

Student 

Machine 

PL 

System/360 

System/ 360 

Student  PL  Machine 

instruction 

bits 

2.94 

X 

106 

6.13 

X 

io7 

20.9 

data  bits 

7.50 

X 

io6 

7.50 

X 

io7 

10.0 

instruction 

memory 

6.52 

X 

106 

4.63 

X 

10  7 

7.10 

accesses 

data  memory 

accesses 

1.68 

X 

io7 

4.11 

X 

io7 

2.45 

instruction 

bits 

5.94 

X 

io7 

1.37 

X 

109 

23.0 

accessed 

data  bits  accessed 

6.86 

X 

108 

1.22 

X 

io9 

1.77 

Table  6.3.6  Ratio  of  Cost  Measure  Terms  for  Student  PL 
Machine  -  System/ 360  Comparison 


Value  from 
Table  6.3.6 

2.94  x  106 
6.52  x  106 

5.94  x  107 


Table  6.3.7  Test 


Value  computed 

Relative 

from  Table  5.10.1 

Error 

3.14  x  106 

6.82% 

6.67  x  106 

2 . 34% 

10.1% 


Machine 


Term 

instruction  bits 

instruction  memory 
accesses 

instruction  bits 
accessed 


6.54  x  107 


of  Covering  Error  for  Student  PL 
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Without  specifying  weighting  factors  It  is  not  possible  to  draw 
firm  conclusions  about  the  superiority  of  one  computer  to  another 
from  the  data  in  Table  6.3.6. 

We  discussed  earlier  the  issue  of  possible  errors  in  the 
evaluation  process  due  to  an  incomplete  covering  of  the  collection 
of  sample  programs  by  the  set  of  fragments.  One  way  to  estimate  the 
magnitude  of  this  covering  error  is  to  compare  the  actual  results 
of  compilation  and/or  execution  with  those  predicted  from  the 
fragment  tabulation.  Another  way  would  be  to  measure  the  covering 
error  at  the  same  time  the  fragment  tabulations  are  performed.  To 
check  our  results,  we  compared  the  values  of  the  terms  relating 
to  number  of  bits  of  instruction,  number  of  instruction  memory 
accesses,  and  number  of  bits  of  instruction  accessed,  in  Table  6.3.6 
with  equivalent  values  computed  from  the  distribution  of  compiled 
and  executed  instructions  in  Table  5.10.1.  It  was  not  possible  to 
check  all  terms  of  the  measure  from  this  data  since  not  all  data 
dependencies  could  be  resolved.  The  results  of  our  test  are 
presented  in  Table  6.3.7.  The  relatively  high  error  for  number  of 
bits  of  instruction  accessed  is  at  least  partially  due  to  the 
assumption  made  in  note  3  of  Table  6.3.4.  We  feel  that  relative 
errors  of  the  magnitude  given  in  Table  6.3.7  are  acceptable  in  light 
of  the  order  of  magnitude  difference  in  most  terms  of  the  cost 
measure.  Reduction  of  the  covering  error  can  be  achieved  by 
increasing  the  level  of  detail  specified  in  the  programming  language 
fragments  and  by  making  fewer  approximations  in  determining  the  object 
program  images  for  each  fragment.  Not  unexpectedly,  reduction  in  the 
relative  error  is  achieved  only  at  the  cost  of  additional  effort 
required  to  perform  the  evaluation 
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6.4  Evaluation  Considerations 

The  programming  language  fragment  data  used  in  our  evaluation 
experiment  can  be  analyzed  in  several  ways  to  provide  further 
insight  into  the  differences  between  the  computers  being  evaluated. 
The  summation: 


T(P) 

j 


1  1 


n 

+  Z 
i=k+l 


B(P)  Cp)dCP) 

l  nij  j 


gives'  the  contribution  of  fragment (1  <  j  <,m)  to  the  value  of  the 
cost  measure.  The  magnitude  of  tP^  is  an  indication  of  the  cost 
incurred  in  using  the  fragment  on  computer  p.  By  comparing  the 
values  of  tH^  for  different  computers  we  can  determine  which 
fragments  are  implemented  economically  on  each. 

We  performed  a  modified  version  of  this  analysis  on  the  data 
from  the  Student  PL  machine/System  360  evaluation  experiment. 

Since  we  have  not  specified  values  for  the  uj^'s,  we  could  not 


compute  Tj 


(P) 


Instead  we  examined  each  term  associated  with  each 


fragment  and  q^?^d^^).  In  our  simple  analysis  we 

considered  only  fragments  for  which  the  magnitude  of  at  least  one 
term  differed  by  more  than  two  orders  of  magnitude  between  the  two 
computers.  We  feel  that  even  this  simple  analysis  gives  a  good 
indication  of  the  relative  strengths  and  weaknesses  of  each  computer. 

From  this  fragment-by- fragment  examination  we  were  able  to 
pin-point  several  areas  where  the  Student  PL  machine  was  markedly 
less  expensive  than  the  System/ 360: 

1)  Procedure/ function  overhead.  The  single  instruction 
procedure  call  and  return  mechanism  on  the  Student  PL 
machine  corresponds  to  a  long  sequence  of  machine 
instructions  and  builtin  function  calls  on  the  System/360. 
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2)  Array  Assignments.  A  single  STORE  or  STORED  instruction 
on  the  Student  PL  machine  vs.  a  DO  loop  expansion  on  the 
System/360.  The  System/360  was  heavily  penalized  by  the 
incredible  fact  that  the  PL/I(F)  compiler  generates  code 
to  check  the  range  of  compiler  generated  subscripts. 

3)  Character  string  operations.  The  System/360  implementation 
made  heavy  use  of  dynamically  created  temporary  storage 
and  very  general  builtin  functions  to  do  operations  on 
character  strings. 

4)  Type  conversions.  The  System/360  implementation  required 
at  least  two  levels  of  builtin  function  call  for  each  type 
conversion.  The  same  conversions  were  hardware  operations 
on  the  Student  PL  machine. 

5)  Use  of  constants  of  type  FIXED.  The  LITERAL  instruction 
on  the  Student  PL  machine  made  the  main  difference. 

6)  Up-level  addressing.  The  Student  PL  machine  display  vs. 
loading  of  address  constants  on  the  System/360. 

There  were  also  fragments  for  which  the  System/360  was  noticably 

more  economical: 

1)  Conditional  statements.  Pessimistic  assiomptions  about  the 
way  the  Student  PL  machine  manipulated  stacks  made  the 
cost  of  implementing  IF-THEN  fairly  high. 

2)  Declaration  and  initialization  of  variables.  The  Student 
PL  machine  used  more  memory  references  to  consult  the 
run-time  symbol  table  and  to  initialize  each  variable. 

The  relative  advantage  of  the  System/ 360  would  be  reduced 
if  it  were  required  to  initialize  all  variables  for 
undefined  value  checking  (Table  6.3.3,  Note  2). 

3)  Forward  GO  TO's.  The  general  Student  PL  machine  stack 
manipulations  are  the  main  difference.  Note  that  this 
fragment  pertains  only  to  the  GO  TO  statement  and  not 
to  compiler  generated  branches. 

4)  Allocation  of  array  storage.  The  Student  PL  machine  was 
penalized  for  the  initialization  of  each  array  element. 

We  are  reluctant  to  draw  strong  conclusions  from  these  observations 
in  the  absence  of  concrete  values  for  the  weighting  factors. 
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The  evaluation  performed  in  this  chapter  compared  a  general 
purpose  computer  capable  of  implementing  many  programming  languages 
against  a  computer  specifically  tailored  to  the  implementation  of 
one  language.  One  result  of  this  particularization  of  the  machine 
was  a  substantial  reduction  in  all  terms  relating  to  the  size  of 
programs.  We  can  conjecture  what  would  happen  if  the  Student  PL 
machine  were  extended  to  implement  other  programming  languages. 

As  long  as  the  other  languages  were  similar  to  Student  PL  (e.g., 
FORTRAN,  Algol  60,  Algol  68,  more  PL/I)  we  would  not  expect  a 
substantial  increase  in  the  size  of  programs.  Many  of  the  Student 
PL  machine  instructions  could  be  usedj  as  is^  to  implement  the  data 
access,  control,  arithmetic,  comparison,  and  storage  allocation 
constructs  in  these  languages.  Of  course  there  would  have  to  be 
new  machine  instructions  to  implement  language  features  which  have 
no  equivalent  in  Student  PL  (e.g.,  Algol  60  call-by-name).  In 
the  Student  PL  machine,  47  instructions  are  encoded  in  8  bits 
(allowing  for  the  special  encoding  of  the  NAME,  LOAD,  and  LITERAL 
instructions).  Adding  one  bit  to  each  instruction  syllable  (a 
12.5%  size  increase)  provides  enough  space  to  encode  256  new 
instructions,  more  than  enough  to  implement  several  new  languages. 

If  the  Student  PL  machine  were  extended  to  implement 
languages  like  LISP,  SNOBOL  4,  or  COBOL  which  require  quite  different 
kinds  of  data  representation  and  control  flow, very  substantial 
changes  would  be  required  in  the  structure  of  the  Student  PL  machine. 
Without  specifying  these  changes  in  detail  it  would  be  very 
difficult  to  predict  the  effect  on  machine  performance. 
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Suppose  instead  of  comparing  the  Student  PL  implementation 
to  a  production  implementation  like  PL/I(F)  we  had  choosen  to 
compare  it  against  a  student-oriented  language  implementation 
like  Algol-W  or  PL/C.  From  our  experience  in  tabulating  cost 
measure  terms  for  each  language  fragment  (cf . ,  Figufe  6.3.1) 
and  from  our  knowledge  of  the  Algol-W  and  PL/C  implementations, 
we  conjecture  that  there  would  have  been  little  change  in  our 
results.  We  believe  that  even  the  best  possible  System/360 
code  will  be  less  dense  than  the  corresponding  Student  PL  machine 
code.  The  bulk  of  the  System/360  code  is  due  to' an  extremely 
bad  match  between  the  semantics  of  high-level  programming 
languages  and  the  order  code  of  the  System/360.  Consider  the 
example  in  Figure  6.3.1,  even  the  best  compiler  can't  get 
around  the  fact  that  it  takes  a  minimum  of  four  instructions 
(128  bits)  to  test  a  subscript  against  an  upper  and  lower 
bound  or  that  it  takes  three  instructions  to  calculate  the 
subscript  polynomial. 
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Chapter  7  -  Conclusion 
7 . 1  Summary- 

In  this  thesis  we  have  explored  the  use  of  experimental 
techniques  in  two  interrelated  areas:  the  design  and  evaluation 
of  language-directed  computers.  In  Chapter  2  we  described  a  procedure 
for  designing  experiments  that  would  suggest  possible  improvements 
in  the  design  of  a  language-directed  computer.  Given  a  computer 
designed  to  implement  a  particular  programming  language,  a  measure  of 
computer  cost  which  is  to  be  minimized,  and  a  collection  of 
programs  which  represent  the  workload  of  the  computer,  we  describe 
the  type  of  experiments  which  should  be  conducted  to  suggest  ways 
to  improve  the  performance  of  the  computer  relative  to  the  given 
cost  measure. 

In  the  same  chapter  we  describe  how  previous  work  in  evaluating 
Algol-60  compilers  can  be  expanded  to  provide  a  new  technique  for 
evaluating  and  comparing  the  cost  of  computers  relative  to 
a  given  measure  of  computer  cost.  Given  a  set  of  programs, 
written  in  one  programming  language,  which  represent  the  workload 
of  the  computer,  we  first  create  an  abstract  model  (the  set  of 
programming  language  fragments) ,  and  then  tabulate  the  static  dis¬ 
tribution  of  fragments  in  the  set  of  programs  and  the  dynamic 
distribution  of  fragments  executed  when  the  set  of  programs  is 
executed.  We  then  measure  the  performance  of  a  computer  by  how 
well  it  implements  each  of  the  programming  language  fragments.  By 
determining  the  effect  of  each  fragment  on  the  value  of  the  given 
cost  measure,  the  static  and  dynamic  distributions  of  fragment 
occurrences  can  be  used  to  compute  an  overall  value  of  the  cost 
measure  for  a  given  computer. 
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In  Chapters  3-6  we  demonstrated  the  validity  of  our  technique 
through  a  case  study  of  the  design  and  evaluation  of  a  language 
directed  computer  for  a  dialect  of  PL/I.  In  Chapter  3  we  describe 
the  dialect  called  Student  PL  and  in  Chapter  4  we  describe  an  initial 
computer  designed  to  implement  the  language.  In  Chapter  5  we 
described  experiments  set  up  to  suggest  improvements  in  the  design 
of  the  machine.  Using  the  results  of  these  experiments  we  make 
the  suggested  changes  in  the  design  of  the  machine.  In  Section 
5.10  we  evaluate  the  effect  of  these  changes  and  show  that  subs  tan tual 
improvements  in  machine  performance  have  been  obtained. 

In  Chapter  6  we  illustrate  the  use  of  our  experimental 
evaluation  technique  to  compare  the  performance  of  the  Student 
PL  machine  with  that  of  a  contemporary  computer- the  IBM  System/ 360. 

For  a  typical  measure  of  computer  cost  we  show  that  the 
Student  PL  machine  has  a  smaller  value  for  each  component  of  the 
measure.  An  absolute  evaluation  of  the  two  computers,  which  would 
require  assigning  values  to  weighting  factors  in  the  cost 
measure,  is  beyond  the  scope  of  this  thesis. 

In  the  process  of  accomplishing  our  intended  goal,  to 
provide  new  tools  for  the  design  and  evaluation  of  language 
directed  computers,  we  also  produced  a  number  of  useful  by-products: 

1)  the  design  of  the  Student  PL  machine  (Chapters  4  and  5) , 

2)  the  Machine  Description  Language  (Chapter  4)  -  incomplete 
in  some  respects,  but  a  start  toward  a  convenient  notation 
for  the  high-level  description  of  computer  architectures, 

3)  Student  PL  -  a  PL/I  dialect  specifically  designed  for 
instructional  purposes.  [Wortman  72]  describes  the 
design  philosophy  behind  this  language, 
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4)  the  tabulation  of  static  and  dynamic  characteristics 
of  Student  PL  programs  (Chapters  5-6  and  Appendix  D) 

-  we  know  of  no  other  study  which  provides  nearly 
as  much  detail  about  the  operating  characteristics 
of  programs  in  a  high-level  programming  language  on 
a  stack  computer. 

The  design  and  evaluation  procedures  described  in  this  thesis 
are  the  beginnings  of  a  new  approach  to  computer  design  and 
evaluation.  In  the  next  section  we  discuss  some  possible  directions 
for  future  research. 
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7.2  Future  Research 


In  this  thesis  we  have  provided  new  tools  for  the  design 
and  evaluation  of  language-directed  computers.  There  are  many 
ways  that  the  work  which  we  have  begun  might  be  extended  in  the 
future . 

1)  There  is  no  inherent  reason  why  our  techniques 
should  be  applied  only  to  language-directed  machines. 

We  hope  our  work  will  encourage  designers  of  many 
types  of  computers  to  use  experimentation  in  the 
improvement  and  evaluation  of  their  designs. 

2)  It  should  be  possible  to  establish  standard  programming 
language  fragment  distributions  for  particular  computer 
application  areas  (e.g.,  banking).  Thus  users  in  a 
particular  area  could  build  composite  data  bases  for 
evaluating  computers  to  suit  their  needs  without  any 
danger  of  compromising  the  proprietary  nature  of  the 
programs  used  to  obtain  the  distributions. 

3)  The  tabulation  of  cost  measure  terms  for 

common  programming  languages  should  be  automated  to 
make  our  evaluation  technique  more  economical. 

4)  An  investigation  of  ways  to  automate  the  collection  of  static 
and  dynamic  occurrences  of  programming  language  fragments. 
Some  interesting  work  has  already  been  done  in  this 

area,  but  a  fully  automatic  system  is  not  yet  available. 

An  investigation  in  more  detail  of  the  problem  of  covering 
error  mentioned  in  Chapter  6. 

6)  Compilers  which  perform  extensive  optimizations  on 
object  programs  are  difficult  to  evaluate  without 
using  a  very  large  number  of  programming  language 
fragments.  It  is  frequently  necessary  to  provide 
contextual  information  as  a  part  of  the  fragment  definition 
(e.g.  ,  "reference  to  an  element  of  a  single  dimensional 
array  including  use  of  a  loop  index  variable") .  More 
economical  ways  to  obtain  performance  information  should 
be  explored. 
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Appendix  B.  Implementation  of  Student  PL  Statements 

This  appendix  consists  of  figures  illustrating  the  implementation 
of  Student  PL  statements  on  the  Student  PL  machines  discussed  in  the 
text.  Each  figure  consists  of  three  parts: 

a)  a  Student  PL  statement , 

b)  the  sequence  of  machine  instructions  used  to  implement  the  statement 
on  the  initial  machine  described  in  Chapter  4, 

c)  the  sequence  of  machine  instructions  used  to  implement 
the  statement  on  the  improved  Student  PL  machine 
described  in  Chapter  5. 

In  these  figures  the  instruction  NAME  stands  for  either  a  SHORT_NAME 
or  LONG_NAME  instruction,  the  instruction  LOAD  stands  for  a  SHORT_LOAD 
or  LONG_LOAD  instruction.  The  choice  between  short  and  long  forms 
depends  on  the  address  of  the  variable  or  constant  being  referenced. 
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a)  a(i),  x  = 

bCj,m)  ; 

b)  LINE 

NAME 

NAME 

EVAL 

SUBS 

NAME 

NAME 

NAME 

EVAL 

NAME 

EVAL 

SUBS 

EVAL 

STORE 

STORE 

POP 

k 

a 

1 

1 

X 

b 

j 

m 

2 

c)  NAME 

LOAD 

SUBS 

NAME 

NAME 

LOAD 

LOAD 

SUBS  EVAL 

STORE 

STORED 

a 

1 

1 

X 

b 

j 

m 

2 

Figure  B.l  A  Multiple  Assignment  Statement 
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a)  a(i) 


b(i)*d  +  10*e 


c(i,j)  ; 


b)  LINE  k 

NAME  a 

NAME  i 

EVAL 

SUBS  1 

NAME  b 

NAME  i 

EVAL 

SUBS  1 

EVAL 

NAME  d 

EVAL 

MUL 

NAME  =10 

EVAL 

NAME  e 

EVAL 

MUL 

ADD 

NAME  c 

NAME  i 

EVAL 

NAME  j 

EVAL 

SUBS  2 


EVAL 

SUB 

STORE 

POP 


c)  NAME  a 

LOAD  i 

SUBS  1 

NAME  b 

LOAD  i 

SUBS_EVAL  1 

LOAD  d 

MUL 

LITERAL  10 

LOAD  e 

MUL 
ADD 

NAME  c 

LOAD  i 

LOAD  j 

SUBS_EVAL  2 

SUB 

STORED 


Figure  B.2  Assignment  Statement  and  Arithmetic  Expression 
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a) 


IF  <expression>  THEN  <statement> 


b) 


LINE 


k 

<expression> 


BIT 

NAME 

SWAP 

SUBS 

EVAL 

CALL 


<statement> 


c) 


) 


<expression> 


NAME 

IF1 


— f 


<statement> 


Figure  B.3  Conditional  Statement 


a)  IF  <expression>  THEN  <statement>t  ELSE  <statement>^ 


b) 


LINE 

( 

BIT 

NAME 

SWAP 

SUBS 

EVAL 

CALL 


k 

<expression> 


1 


<statement> 


<s tatement> 


£ 

t 


c) 


) 

NAME 

IF2 


<expression> 


<s  tatement> 

f 

<s tatement>t 


Figure  B.4  Conditional  Statement 
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a)  DO  WHILE  <expression>  ; 
statement  list> 

END  ; 


b) 


EVAL 

CALL 

CYCLE 


statement  list> 


c) 


LOAD 

CALL 


tZE 


fb 


CRET 
LOAD  ~ 
CALL 
CYCLE 


<expression> 

- >[=E 


<statement  list> 


Figure  B.5  DO  WHILE  Group 


a)  DO  <variable>  =  <expression>  , 
<statement  list>  1 

END  ; 


<expression> 


n 


y 


b) 


c) 


LINE  k 


NAME 


CALL 

LINE  k 


LOAD 

CALL 


5> 


<variable> 


Figure  B.6  Iterative  Group  with  Expression  List 
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a)  DO  <variable>  =  <expression>^  TO  <expression>^ 

BY  <expression>^  ; 


statement  list> 
END  ; 


b) 


LINE 

NAME 

EVAL 

CALL 


■*E 


^NAME 

i 

DOS TORE 


) 


NAME  — - 

EVAL 

CALL 


5) 


<variable> 
<expression> ^ 


<expression>^ 

<expression>1 


Cl 


LINE  k 
DOTEST 
CRET 
NAME 
EVAL 
CALL 
DOINCR 
CYCLE 


b 


^  statement  list> 


c) 


LOAD 

CALL 


Figure  B.7  Iterative  DO  Group 
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a)  BEGIN  ;  /*  mth  scope  */ 

statement  list> 

END  ; 


b) 


LINE 

NAME 

ENTER 

POP 


k 


=3=3 

^  SCOPEID  m 


<statement 


list> 


UNDEF 

END  m 


c) 


NAME 

ENTER 

POP 


1  ■ 1 .  3 

SCOPEID  m 


^  <statement  list> 

UNDEF 

END  m 


Figure  B.8  BEGIN-END  Block 
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a)  CALL  <variable>  (  <expression> ...  ,  <expression>n  )  ; 


b)  LINE 

NAME 

) 

k 

<variable> 

<expression>  ^ 

PARAM 

SWAP 

1 

7 

PARAM 

SWAP 

ENTER 

POP 

<expression>n 

n 

n 

c)  NAME 

1 

<variable> 

<expression>^ 

PARAM 

SWAP 

1 

l 

PARAM 

SWAP 

ENTER 

POP 

<expression>n 

n 

n 

Figure  B.9  A  Typical  Procedure  Call 
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a) 


x  =  <function>  (  <expression> 


•  • 


Is 


<expression>n  )  ; 


LINE 

k 

NAME 

X 

NAME 

<function> 

/ 

<expression> 

PARAM 

SWAP 

1 

^  <expression>n 

PARAM  n 

SWAP 

ENTER  n 

STORE 

POP 


c)  NAME 

/ 


x 

expressions 


1 

<expression> 

LITERAL 

n 

BFUNC 

<£unction> 

STORED 

Figure  B.1Q  Typical  Builtin  Function  Call 


1 
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Appendix  C 


Student  Programming  Assignments 


186 


1)  Write  a  program  to  read  in  four  numbers  and  store  them  in 
variables  ’a’,  'b',  'c1,  'd!,  add  them  and  store  the  result 
in  ’sum',  and  print  the  result  'sum". 

2)  Write  a  program  which  reads  in  one  at  a  time,  a  sequence 
of  numbers.  If  two  consecutive  numbers  in  the  sequence 
have  the  same  value,  print  them  out.  Assume  the  sequence 
ends  with  two  zeroes. 

3)  Write  a  program  that  prints  out  a  pretty  picture. 

4)  Consider  an  English  passage.  You  are  required  to  determine 
the 

1)  number  of  words  (1-12  characters) , 

2)  number  of  sentences  (1-10  words) , 

3)  frequency  distribution,  mean,  and  standard 
deviation  of  the  number  of  characters  in  a  word,  and 

4)  frequency  distribution,  mean,  and  standard  deviation 
of  the  number  of  words  in  a  sentence. 

Print  a  histogram  to  display  each  of  the  frequency 
distributions,  label  your  output.  An  input  paragraph  of 
1-15  sentences  will  be  provided. 

5)  Let  SKIN  be  a  10x10  patch  of  healthy  skin  cells  with  one 
infected  cell  near  the  center.  Each  time-step  an  infected 
cell  has  probability  0.5  of  infecting  each  of  its  healthy 
neighbors . —  After  6  time  steps  an  infected  cell  becomes  immune 
for  4  more  steps,  then  becomes  healthy  once  again.  Simulate 
this  situation  on  the  computer,  printing  the  skin  at  each  step. 
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Appendix  D 


Additional  Machine  Statistics 
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Table  D.l  Distribution  of  Source  Statements  by  Type  (From  Table  5.3.1) 


Instruction 

Triple 

Occurrences 

Percentage 

NAME 

NAME 

EVAL 

34586 

5.8 

EVAL 

NAME 

EVAL 

33407 

5.7 

NAME 

EVAL 

NAME 

32404 

5.4 

POP 

NAME 

NAME 

16091 

2.7 

NAME 

16090 

2.7 

NAME 

EVAL 

CALL 

14380 

2.4 

STORE 

POP 

NAME 

13539 

2.3 

PARAM 

SWAP 

NAME 

13457 

2.2 

NAME 

NAME 

12893 

2.2 

NAME 

EVAL 

CAT 

11999 

2.0 

SWAP 

NAME 

EVAL 

11995 

2.0 

NAME 

EVAL 

SUBS 

11766 

2.0 

EVAL 

PARAM 

SWAP 

10941 

1.8 

NAME 

EVAL 

PARAM 

10917 

1.8 

PARAM 

SWAP 

ENTER 

9809 

1.6 

NAME 

PARAM 

SWAP 

8603 

1.4 

EVAL 

CAT 

NAME 

8217 

1.4 

NAME 

NAME 

PARAM 

7936 

1.3 

CAT 

NAME 

EVAL 

7790 

1.3 

POP 

7775 

1.3 

NAME 

EVAL 

STORE 

7722 

1.3 

EVAL 

STORE 

POP 

7396 

1.2 

EVAL 

SUBS 

EVAL 

7265 

1.2 

EVAL 

CALL 

6904 

1.2 

CALL 

6904 

1.2 

LFUNC 

POP 

NAME 

6461 

1.1 

BLOCK 

6124 

1.0 

NAME 

NAME 

NAME 

5868 

1.0 

EVAL 

CALL 

NAME 

5680 

.95 

STORE 

POP 

5350 

.89 

CAT 

LFUNC 

POP 

5297 

.88 

CRET 

NAME 

EVAL 

5214 

.87 

CYCLE 

5171 

.86 

NAME 

EVAL 

ADD 

5019 

.84 

SUBS 

EVAL 

NAME 

4905 

.82 

CALL 

NAME 

NAME 

4528 

.76 

EVAL 

CAT 

LFUNC 

4523 

.76 

NAME 

SWAP 

SUBS 

4360 

.73 

SWAP 

SUBS 

EVAL 

4360 

.73 

SUBS 

EVAL 

CALL 

4360 

.73 

BIT 

NAME 

SWAP 

4351 

.73 

ADD 

STORE 

POP 

4227 

.71 

ENTER 

STORE 

POP 

4113 

.69 

POP 

NAME 

EVAL 

4111 

.69 

SWAP 

ENTER 

CAT 

4078 

.68 

DOSTORE 

NAME 

EVAL 

3989 

.67 

NAME 

EVAL 

DOSTORE 

3915 

.65 

EVAL 

DOSTORE 

NAME 

3915 

.65 

Table  D.2  Initial  Machine  -  Distribution  of  Compiled  Instruction  Triples 
(LINE  instruction  suppressed) 
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Instruction  Triple 


Occurrences  Percentage 


DOTEST 

3904 

.65 

DOTEST 

CRET 

3904 

.65 

DOTEST 

CRET 

NAME 

3904 

.65 

EVAL 

CALL 

DOINCR 

3904 

.65 

CALL 

DOINCR 

CYCLE 

3904 

.65 

DOINCR 

CYCLE 

3904 

.65 

CAT 

NAME 

NAME 

3794 

.63 

EVAL 

SUBS 

NAME 

3695 

.62 

EVAL 

ADD 

STORE 

3578 

.60 

ENTER 

CAT 

NAME 

3366 

.56 

EVAL 

LFUNC 

POP 

3228 

.54 

NAME 

EVAL 

LFUNC 

3160 

.53 

All  Other  Triples  114070  19.0 

(each  <  0.5%) 


Table  D.2  (cont.) 
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Instruction 

Pair 

Occurrences 

Percentage 

SHORT  NAME 

SHORT  LOAD 

19575 

5.4 

SHORT  NAME 

LITERAL 

17633 

4.9 

LITERAL 

LITERAL 

14525 

4.0 

SHORT  LOAD 

CALL 

13796 

3.8 

SHORT  NAME 

12101 

3.4 

SHORT  LOAD 

SHORT  LOAD 

12081 

3.4 

SHORT  LOAD 

CAT 

11714 

3.3 

LITERAL 

BFUNC 

11712 

3.3 

STORED 

SHORT  NAME 

9160 

2.5 

LONG  NAME 

LFUNC 

8710 

2.4 

LFUNC 

POP 

8678 

2.4 

SHORT  LOAD 

LITERAL 

7750 

2.2 

CAT 

SHORT  LOAD 

7573 

2.1 

SHORT  LOAD 

SUBSEVAL 

6737 

1.9 

STORED 

5350 

1.5 

CAT 

LONG  NAME 

5303 

1.5 

SHORT  NAME 

SHORT  NAME 

5290 

1.5 

CALL 

4739 

1.3 

LITERAL 

STORED 

4580 

1.3 

LITERAL 

SHORT  LOAD 

4428 

1.2 

SUBSEVAL 

LITERAL 

4290 

1.2 

ADD 

STORED 

4227 

1.2 

STORED 

SHORT  LOAD 

4102 

1.1 

BFUNC 

STORED 

4050 

1.1 

POP 

SHORT  LOAD 

3990 

1.1 

BFUNC 

CAT 

3977 

1.1 

DOTEST 

3904 

1.1 

CALL 

DOINCR 

3904 

1.1 

DOINCR 

3904 

1.1 

LITERAL 

ADD 

3842 

1.1 

LITERAL 

DOSTORE 

3793 

1.1 

CAT 

SHORT  NAME 

3784 

1.1 

DOTEST 

SHORT  LOAD 

3721 

1.0 

SHORT  LOAD 

3688 

1.0 

SHORT  LOAD 

SUBS 

3589 

1.0 

DOS  TORE 

LITERAL 

3585 

1.0 

SCOPEID 

3577 

.99 

SHORT  LOAD 

LONG  NAME 

3073 

.85 

SHORT  NAME 

IF1 

2964 

.82 

POP 

SHORT  NAME 

2690 

.75 

SUBS 

LITERAL 

2642 

.73 

SHORT  LOAD 

STORED 

2601 

.72 

POP 

2425 

.67 

Table  D.3 

Improved  Machine 

-  Distribution  of  Compiled 

Instruction  Pairs. 
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Instruction  Pair 

Occurrences 

Percentage 

LITERAL 

SHORT  NAME 

2224 

.62 

BFUNC 

SHORT  LOAD 

1860 

.52 

CALL 

SHORT  NAME 

1857 

.52 

SHORT  NAME 

ENTER 

1758 

.49 

GALL 

SHORT  LOAD 

1739 

.48 

SCOPE ID 

SHORT  NAME 

1661 

.46 

LITERAL 

SUB 

1654 

.46 

END 

1650 

.  46 

All  other  pairs 

(each  <  0.5%) 

71871 

20.0 

Table  D.3  (con5!) 


Instruction  Triple  Occurrences  Percentage 


SHORT  NAME 

12101 

3.2 

LONG  NAME 

LFUNC 

POP 

8678 

2.3 

CAT 

SHORT  LOAD 

CAT 

7556 

2.0 

SHORT  NAME 

SHORT  LOAD 

SHORT  LOAD 

7252 

1.9 

SHORT  NAME 

SHORT  LOAD 

5890 

1.5 

STORED 

5350 

1.4 

CAT 

LONG  NAME 

LFUNC 

5299 

1.4 

SHORT  NAME 

LITERAL 

LITERAL 

4846 

1.3 

CALL 

4739 

1.2 

LITERAL 

LITERAL 

LITERAL 

4728 

1.2 

SHORT  NAME 

LITERAL 

4698 

1.2 

SHORT  LOAD 

CALL 

4505 

1.2 

LITERAL 

LITERAL 

BFUNC 

4362 

1.1 

SHORT  LOAD 

CAT 

LONG  NAME 

4349 

1.1 

STORED 

SHORT  NAME 

LITERAL 

4110 

1.1 

SHORT  NAME 

SHORT  LOAD 

LITERAL 

4058 

1.1 

SHORT  LOAD 

CAT 

SHORT  LOAD 

4056 

1.1 

LITERAL 

BFUNC 

STORED 

4050 

1.1 

LITERAL 

BFUNC 

CAT 

3977 

1.0 

DOTEST 

3904 

1.0 

CALL 

DOINCR 

3904 

1.0 

DOINCR 

3904 

1.0 

LFUNC 

POP 

SHORT  LOAD 

3864 

1.0 

STORED 

NAME 

SHORT  LOAD 

3853 

1.0 

SHORT  LOAD 

SUBSEVAL 

LITERAL 

3845 

1.0 

SHORT  NAME 

SHORT  LOAD 

SUBSEVAL 

3794 

.99 

SHORT  NAME 

LITERAL 

DOSTORE 

3728 

.97 

SHORT  LOAD 

CALL 

DOINCR 

3726 

.97 

DOTEST 

SHORT  LOAD 

3721 

.97 

LITERAL 

SHORT  LOAD 

CALL 

3697 

.96 

SHORT  LOAD 

3688 

.96 

DOTE ST 

SHORT  LOAD 

CALL 

3681 

.96 

SCOPE1D 

3577 

.93 

DOS TORE 

LITERAL 

LITERAL 

3558 

.93 

LITERAL 

DOSTORE 

LITERAL 

3549 

.93 

LITERAL 

LITERAL 

SHORT  LOAD 

3477 

.91 

SHORT  NAME 

LITERAL 

BFUNC 

3356 

.87 

CAT 

SHORT  NAME 

LITERAL 

3279 

.85 

SHORT  NAME 

LITERAL 

STORED 

3139 

.82 

SHORT  LOAD 

LONG  NAME 

LFUNC 

3053 

.80 

SHORT  LOAD 

SHORT  LOAD 

CAT 

2820 

.74 

BFUNC 

CAT 

SHORT  LOAD 

2717 

.71 

SHORT  LOAD 

LITERAL 

ADD 

2697 

.70 

SHORT  LOAD 

SHORT  LOAD 

SUBSEVAL 

2583 

.67 

SHORT  LOAD 

CAT 

SHORT  NAME 

2556 

.67 

LITERAL 

ADD 

STORED 

2524 

.66 

POP 

2425 

.63 

Table  D.4  Improved  Machine  -  Distribution  of  Compiled 

Instruction  Triples  (LINE  instruction  suppressed) 
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Instruction  Triple 

Occurrences 

Percentage 

LITERAL 

STORED 

SHORT  NAME 

2409 

.63 

STORED 

SHORT  LOAD 

CALL 

2351 

.61 

LFUNC 

POP 

SHORT  NAME 

2314 

.60 

ADD 

STORED 

SHORT  NAME 

2140 

.56 

SHORT  NAME 

SHORT  LOAD 

STORED 

2102 

.55 

All  Other 

Triples  (each< 

0.5%) 

173121 

45.1 

Table 

D.4  (cont.) 
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Length 

Occurrences 

Percentage 

Cumulative 

Percentage 

[  0,2°) 

1427 

9.4 

9.4 

[2°, 21) 

4973 

32.5 

41.9 

[21,22) 

1537 

10.1 

52.0 

[22,23) 

1556 

10.2 

62.2 

[23,24) 

1490 

9.8 

72.0 

[24 ,23) 

2357 

15.4 

87.4 

[25, 26) 

1784 

11.7 

99.1 

[26,27) 

88 

0.6 

99.7 

[2?,28) 

51 

0.3 

100.0 

[28,29) 

2 

0.0 

100.0 

Table  D.5 


Distribution  of  Length  of  Character  String  Constants 
Appearing  in  Programs 


Number  of 
Characters 

Occurrences 

Percentage 

Cumulative 

Percentage 

[  o  , 

2°  ) 

232 

24.2 

24.2 

[  2°  , 

21  ) 

5 

.5 

24.7 

[  21  , 

22  ) 

30 

3.1 

27.8 

[  22  , 

23) 

13 

1.4 

29.2 

[  23  , 

2 4  ) 

68 

7.1 

36.3 

[  2 4  , 

25  ) 

49 

5.1 

41.4 

[  25  , 

26  ) 

67 

7.0 

48.4 

[  26  , 

2 7  ) 

91 

9.5 

57.9 

[  2 7  , 

28  ) 

61 

6.4 

64.3 

[  28  , 

29  ) 

298 

31.1 

95.4 

[  29  , 

210) 

37 

3.9 

99.3 

I  210, 

2H) 

6 

.6 

99.9 

[  212, 

213) 

1 

.1 

100.0 

Table  D.6  Distribution  of  Total  Length  of  Character  String 
Constants  per  Program 
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Number  of 

Number  of 

Cumulative 

Statements 

Programs 

Percentage 

Percentage 

C  0,  5] 

10 

1.0 

1.0 

(  5,10] 

58 

6 . 0 

7.0 

(10,15] 

113 

11.8 

18.8 

(15,20] 

54 

5.6 

24.4 

(20,25] 

29 

3.0 

27.4 

(25,30] 

34 

3.5 

30.9 

(30,35] 

45 

4.7 

35.6 

(35,40] 

59 

6.2 

41.8 

(40,45] 

119 

12.5 

54.3 

(45,50] 

95 

9.9 

64.2 

(50,55] 

102 

10.6 

74.8 

(55,60] 

86 

9.0 

83.  8 

(60,65] 

54 

5.6 

89.4 

(65,70] 

40 

4.2 

93.6 

(70,75] 

21 

2.2 

95.8 

(75,80] 

19 

2.0 

97.8 

(80,85] 

13 

1.4 

99.2 

(85,90] 

8 

.8 

100.0 

Table  D.7 

Distribution  of  Number 

of  Student  PL 

Statements 

per  Program 
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Number  of 

Number  of 

Scopes 

Programs 

Percentage 

1 

650 

67.5 

2 

75 

7.8 

3 

156 

16.2 

4 

58 

6.0 

5 

6 

0 . 6 

6 

16 

1.7 

7 

2 

0.2 

Table  D.8 

Distribution  of  Scopes 

(Blocks  and  Procedures) 

per  Program 


Length  in 
Syllables 

Occurrences 

Percentage 

Cumulative 

Percentage 

[  o  , 

2°  ) 

3001 

11.7 

11.7 

[  2°  , 

21  ) 

0 

.0 

11.7 

[  21  , 

22  ) 

163 

.6 

12.3 

[  22  , 

23  ) 

1966 

7.7 

20.0 

[  23  , 

24  ) 

8408 

32.8 

52.8 

[  2 4  , 

25  ) 

6977 

27.2 

80.0 

[  25  , 

26  ) 

2442 

9.5 

89.5 

[  26  , 

27) 

1916 

7.5 

97.0 

[  27  , 

2 8  ) 

355 

1.4 

98.4 

[  28  , 

29  ) 

350 

1.4 

99.8 

[  29  , 

210) 

32 

.1 

99.9 

[210, 

211) 

8 

.0 

100 » 0 

[  2U, 

212) 

29 

.1 

Table  D„9  Initial  Machine  -  Distribution  of  Length  o'f 
Compiled  Program  Segments 
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Maximum  Depth 
of  Stack 

Number  of 
Programs 

Percentage 

Cumulative 

Percentage 

[  o 

,  2°  ) 

0 

.0 

.0 

[  2° 

,  21  ) 

6 

.6 

.6 

[  21 

,  22  ) 

57 

6.0 

6.6 

[  22 

,  23  ) 

563 

58.7 

65.3 

[  23 

,  2 4  ) 

257 

26.8 

92.1 

[  2 4 

,  25  ) 

76 

7.9 

100.0 

Table  D.10  Initial  Machine  -  Distribution  of  Maximum  Segment 
x  Stack  Usage  During  Program  Execution 


Maximum  Depth 
of  Stack 

Number  of 
Programs 

Percentage 

Cumulative 

Percentage 

[  o 

,  2°  ) 

0 

.0 

.0 

[  2° 

,  21  ) 

679 

70.8 

70.8 

[  21 

,  22  ) 

262 

27.3 

98.1 

[  22 

.  23  ) 

13 

1.4 

99.5 

[  23 

,  2«  ) 

5 

.5 

100.0 

Table  D.ll  Initial  Machine  -  Distribution  of  Maximum  Scope 
Stack  Usage  during  Program  Execution 
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Number  of 

Number  of 

Percentage 

Cumulative 

Entries 

Programs 

of  Total 

Percentage 

[  0  ,  22  ) 

1 

0.1 

0.1 

[  22,  23  ) 

4 

0.4 

0.5 

[  23,  2 4  ) 

205 

21.4 

21.9 

[  24,  25  ) 

42 

4.4 

26.3 

[  2S,  2 6  ) 

340 

35.6 

61.9 

[  26,  2 7  ) 

363 

38.0 

99.9 

[  27,  28  ) 

1 

0.1 

100.0 

Table  D.12  Initial  Machine  -  Distribution  of  Symbol  Table 
Entries  required  per  Program 
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Number  of 

Number 

Percentage 

Cumulative 

Syl lables 

Programs 

Percentage 

[0  ,  23  ) 

0 

.0 

.0 

[  23  ,  24  ) 

4 

.4 

.4 

[  24  ,  25  ) 

0 

.0 

.4 

[  25  ,  26  ) 

4 

.4 

.8 

[  26  ,  27  ) 

79 

8.2 

9.0 

[  27  ,  28  ) 

138 

14.4 

23.4 

[  28  ,  29  ) 

32 

3.3 

26.7 

[  29  ,  210) 

254 

26.6 

53.3 

[  210,  2U) 

373 

38.9 

92.2 

[  21 1 ,  212) 

66 

6.9 

99.1 

[  212,  213) 

9 

.9 

100.0 

Table  D.13 

Initial  Machine 

-  Distribution 

of  String/Segment 

Storage  Required  per  Program 


Words  of  Array 
Descriptor 

Number  of 
Programs 

Percentage 

Cumulative 

Percentage 

[  o 

,  2°  ) 

302 

31.5 

31.5 

[  2° 

,  21  ) 

0 

.0 

31.5 

[  21 

,  22  ) 

146 

15.2 

46.7 

[  22 

.  23) 

379 

39.5 

86.2 

[  23 

,  2 4  ) 

105 

11.0 

97.2 

[  2 4 

,  2^  ) 

25 

2.6 

99.8 

[  25 

,  2 6  ) 

1 

.  1 

99.9 

[  26 

,  2 7  ) 

1 

.1 

100.0 

Table  D.14  Initial  Machine  -  Distribution  of  Total  Array  Descriptor 
Storage  Required  per  Program 
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Maximum  Depth 
of  Stack 

Number  of 
Programs 

Percentage 

Cumulative 

Percentage 

[  o,  2°  ) 

0 

0.0 

0.0 

[  2°,  21  ) 

0 

0.0 

0.0 

[  21,  22  ) 

0 

0.0 

0.0 

[  22 ,  23  ) 

2 

0.2 

0.2 

[  23,  2 4  ) 

203 

21.9 

22.1 

[  24,  2S  ) 

37 

4.2 

26.3 

[  25,  2 6  ) 

185 

20.0 

46.3 

[  26,  27  ) 

497 

53.7 

100.0 

Table  D.15  Initial 

Machine  - 

Distribution  of  Maximum 

i  Data 

Stack  Usage  During  Program  Execution 


Number  of 

Array  Elements 

Number  of 
Programs 

Percentage 

Cumulative 

Percentage 

[  0,2°) 

302 

31.7 

31.7 

[  2°  ,  21  ) 

0 

0.0 

31. 7 

[  21  ,  22  ) 

0 

0.0 

31.7 

[  22  ,  23  ) 

3 

0.3 

32.0 

[  23  ,  24  ) 

4 

0.4 

32.4 

[  24  ,  25  ) 

258 

27.1 

59.5 

[  25  ,  26  ) 

159 

16.7 

76.2 

[  26  ,  2?  ) 

159 

16.7 

92.9 

[  27  ,  28  ) 

54 

5.7 

98.6 

[  28  ,  29  ) 

8 

0.8 

99.6 

[  29  ,  210) 

1 

0.1 

99.7 

[  210 ,  211) 

3 

0.3 

100.0 

Table  D.16  Initial 

Machine  - 

Distribution  of  Array 

Storage 

Allocated  during  Program  Execution 
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Size  in 
Syllables 

Number  of 
Programs 

Percentage 

Cumulative 

Percentage 

[ 

0  , 

2°  ) 

0 

.0 

.0 

[ 

2°  , 

21  ) 

0 

.0 

.0 

[ 

21  , 

22  ) 

0 

.0 

.0 

[ 

22  , 

23  ) 

0 

.0 

.0 

[ 

23  , 

24  ) 

0 

.0 

.0 

[ 

24  , 

25  ) 

0 

.0 

.0 

[ 

25 

26  ) 

3 

.3 

.3 

[ 

26  , 

27  ) 

82 

8.6 

8.9 

[ 

2 7  , 

28  ) 

147 

15.3 

24.2 

[ 

28 

^  y 

29  ) 

26 

2.7 

26.9 

[ 

29  , 

2i0) 

373 

38.9 

65.8 

[ 

210, 

2U) 

297 

31.0 

96.8 

[ 

211, 

212) 

29 

3.0 

99.8 

[ 

,12 
^  y 

213) 

2 

.2 

100.0 

Table  D. 

17  Initial  Machine  - 

Distribution  of  Total 

Program  Size 
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Length  in 
Characters 

Number  of 
Accesses 

Percentage 

Cumulative 

Percentage 

[0,2°) 

16451 

12.7 

12.7 

[  2°,  21  ) 

63917 

49.3 

62.0 

[  21 ,  22  ) 

7310 

5.6 

67.6 

[  22,  23  ) 

11068 

8.5 

76.1 

[  23,  24  ) 

8067 

6.2 

82.3 

[  24,  25  ) 

6724 

5.2 

87.5 

[  25,  26  ) 

14945 

11.5 

99.0 

[  26,  2 7  ) 

564 

0.4 

99.4 

[  27,  28  ) 

311 

0.2 

99.6 

[  28,  2®  ) 

202 

0.2 

99.8 

[  29,  210) 

22 

0.0 

99.8 

Table  D. 18  Initial  Machine  -  Distribution  of  Character  Strings 
Accessed  during  Program  Execution  by  Length 
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Range 

Value 

of 

Number  of 
Accesses 

Percentage 

Cumulative 

Percentage 

[-231, 

0  ) 

8805 

0.9 

- 

[  o  , 

2°  ) 

166063 

16.3 

16.3 

[  2°  , 

21  ) 

259544 

25.5 

41.8 

[  21  , 

22  ) 

193927 

19.0 

60.8 

[  22  , 

23) 

286345 

28.1 

88.9 

[  23  , 

24  ) 

64523 

6.3 

95.2 

[  2 4  , 

25  ) 

9378 

1.0 

96.2 

[  25  , 

2 6  ) 

14466 

1.4 

97.6 

[  26  , 

2 7  ) 

5710 

0.6 

98.2 

[  2 7  , 

28  ) 

3502 

0.3 

98.5 

[  2 8  , 

29  ) 

4433 

0.4 

98.9 

[  29  , 

2 10) 

1991 

0.2 

99.1 

[  210, 

211) 

432 

0.0 

99.1 

[  2U, 

212) 

147 

0.0 

99.1 

[  2l2, 

213) 

34 

0.0 

99.1 

[  213, 

214) 

192 

0.0 

99.1 

Table  D.19  Initial  Machine  -  Distribution  of  FIXED  values 
Accessed  during  Program  Execution 
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Total  Length 
in  Characters 

Number  of 
Programs 

Percentage 

Cumulative 

Percentage 

[  o  ,  2°  ) 

255 

26.6 

26.6 

[  2°  ,  21  ) 

1 

0.1 

26.7 

[  21  ,  22  ) 

1 

0.1 

26.8 

[  22  ,  23  ) 

10 

1.0 

27.8 

[  23  ,  24  ) 

8 

0.8 

28.6 

[  24  ,  25  ) 

20 

2.1 

20.7 

[  2s  ,  26  ) 

48 

5.0 

35.  7 

[  26  ,  27  ) 

40 

4.2 

39.9 

[  27  ,  28  ) 

56 

5.8 

45.7 

[  28  ,  29  ) 

62 

6.5 

52.2 

[  29  ,  2 10) 

112 

11.7 

63.9 

[  2 10 ,  211) 

193 

20.1 

84.0 

[  211,  212) 

88 

9.2 

93.2 

[  212,  213) 

38 

4.0 

97.2 

[  213,  214) 

18 

1.9 

99.1 

[  214,  215) 

4 

0.4 

99.5 

[  215,  216) 

1 

0.1 

99.6 

[  216,  217) 

3 

0.3 

99.9 

[  217,  218) 

1 

0.1 

100.0 

Table  D.20  Initial  Machine  -  Distribution  of  Total  Length  of 
Character  Strings  Created  during  Program  Execution 


207 


' 


